1 |
The 06/09/12, Dale wrote: |
2 |
|
3 |
> I do get it. I CLEARED #1 and #2, there is no usage of #3 and #4 is not |
4 |
> large enough here to matter. So, it is left with #5. |
5 |
> |
6 |
> See the point? The test was a NORMAL emerge with portages work |
7 |
> directory on tmpfs and a NORMAL emerge with portages work directory on |
8 |
> disk and compare the results. The test resulted in little if any |
9 |
> difference. |
10 |
> |
11 |
> If I ran the test and did not clear the cache, then I would expect |
12 |
> skewed results because after the first emerge, some files would be |
13 |
> cached in ram and the drive would not be used. If you clear the cache, |
14 |
> then it has to take the same steps regardless of whether it was run |
15 |
> first, second or third time. |
16 |
|
17 |
What you want to measure is the difference of times required by emerge |
18 |
whether you use a real disk or tmpfs as backend. |
19 |
|
20 |
What you would expect is a difference because a disk is much slower than |
21 |
RAM. |
22 |
|
23 |
What you see is no difference. You won't conclude that disk is as fast |
24 |
as RAM, right? Can you explain why you don't see much difference? No. |
25 |
|
26 |
Here is the explanation: if you have enough RAM, the emerge rapidity |
27 |
will NOT rely on the disk rapidity whatever storage backend you use. It |
28 |
will only rely on the RAM rapidity because of the kernel cache. |
29 |
|
30 |
Now, pretending that whatever backend you use (real disk or tmpfs) never |
31 |
changes the emerge time is WRONG because of the persistence strategy |
32 |
used by the kernel for the kernel cache. |
33 |
|
34 |
When having lot of RAM like you have, the persistence strategy of the |
35 |
kernel cache is NEVER raised in the process. |
36 |
|
37 |
This is exactly what your tests demonstrate demonstrate: if you have |
38 |
enough RAM, the persistence strategy of kernel cache is not raised, so |
39 |
everything happens in RAM, so the emerge times do not differ. |
40 |
|
41 |
-- |
42 |
Nicolas Sebrecht |