1 |
Nicolas Sebrecht wrote: |
2 |
> The 06/09/12, Dale wrote: |
3 |
> |
4 |
>> The point you are missing is this. Between those tests, I CLEARED that |
5 |
>> cache. The thing you and Neil claim that makes a difference does not |
6 |
>> exist after you clear the cache. I CLEARED that cache between EACH and |
7 |
>> every test that was ran whether using tmpfs or not. I did this instead |
8 |
>> of rebooting my system after each test. |
9 |
> We clearly understand that you cleared the cache between the tests. We |
10 |
> pretend that it is not much relevant for your tests because of another |
11 |
> process. |
12 |
> |
13 |
>> So, in theory I would say that using tmpfs would |
14 |
>> result in faster compile times. After testing, theory left the building |
15 |
>> and reality showed that it did not make much if any difference. |
16 |
> Yes, because you did the tests on a system with lot of RAM. |
17 |
> |
18 |
> If the kernel needs to retrieve a file, there is basically the following |
19 |
> workflow: |
20 |
> |
21 |
> 1. retrieve file from kernel cache; |
22 |
> 2. if not found, retrieve file from tmpfs cache; |
23 |
> 3. if not found, retrieve file from swap cache; |
24 |
> 4. if not found, retrieve file from disk cache; |
25 |
> 5. if not found, retrieve file from disk. |
26 |
> |
27 |
> This is simplified workflow but you get the idea. |
28 |
|
29 |
I do get it. I CLEARED #1 and #2, there is no usage of #3 and #4 is not |
30 |
large enough here to matter. So, it is left with #5. |
31 |
|
32 |
See the point? The test was a NORMAL emerge with portages work |
33 |
directory on tmpfs and a NORMAL emerge with portages work directory on |
34 |
disk and compare the results. The test resulted in little if any |
35 |
difference. |
36 |
|
37 |
If I ran the test and did not clear the cache, then I would expect |
38 |
skewed results because after the first emerge, some files would be |
39 |
cached in ram and the drive would not be used. If you clear the cache, |
40 |
then it has to take the same steps regardless of whether it was run |
41 |
first, second or third time. |
42 |
|
43 |
> |
44 |
> Now, what we are saying is that *when you have lot of RAM*, the kernel |
45 |
> never hit 2, 3, 4 and 5. The problem with the kernel cache is that files |
46 |
> stored in this cache are dropped from it very fast. tmpfs allows to have |
47 |
> better files persistence in RAM. But if you have lot of RAM, the files |
48 |
> stored in the kernel cache are /not/ dropped from it which allows the |
49 |
> kernel to work with files in RAM only. |
50 |
> |
51 |
> Clearing the kernel cache between the tests does not change much since |
52 |
> files are stored in RAM again, at the unpack process time. What makes |
53 |
> compilation very slow from the disk are all the _next reads and writes_ |
54 |
> required by the compilation. |
55 |
> |
56 |
>> Well, why say that caching makes a difference then say it doesn't matter |
57 |
>> when those caches are cleared? Either caches matter or it doesn't. |
58 |
> It does make a difference if you don't have enough RAM for the kernel |
59 |
> cache to store all the files involved in the whole emerge process and |
60 |
> every other process run by the kernel during the emerge. |
61 |
> |
62 |
|
63 |
But if you CLEAR the kernel cache between each test, then it doesn't |
64 |
matter either. I am clearing the KERNEL cache which includes pagecache, |
65 |
dentries and inodes. I can see the difference in gkrellm, top and in |
66 |
what the command free gives me. |
67 |
|
68 |
Put another way. I run a emerge on tmpfs and note the emerge times. I |
69 |
reboot. I run the same emerge again with it not on tmpfs. Do we agree |
70 |
that that would result in a actual real result? If yes then using the |
71 |
command to clear the cache is the same as rebooting. It's the whole |
72 |
point of having the feature in the kernel. The file drop_caches when |
73 |
set to 3 with the echo command erases, deletes or whatever you want to |
74 |
call it, the caches. That's from the kernel folks as linked to in |
75 |
another reply. That's not me saying it, it is the kernel folks saying it. |
76 |
|
77 |
Dale |
78 |
|
79 |
:-) :-) |
80 |
|
81 |
-- |
82 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |