1 |
The 06/09/12, Dale wrote: |
2 |
|
3 |
> Then take a look at it this way. If I emerge seamonkey with portage's |
4 |
> work directory on disk and it takes 12 minutes, the first time. Then I |
5 |
> clear the caches and emerge seamonkey again while portage's work |
6 |
> directory is on tmpfs and it is 12 minutes. Then repeat that process a |
7 |
> few times more. If the outcome of all those emerges is 12 minutes, |
8 |
> regardless of the order, then putting portages work directory on tmpfs |
9 |
> makes no difference at all in that case. |
10 |
|
11 |
We fully agree with you, here. |
12 |
|
13 |
> The emerge times are exactly |
14 |
> the same regardless of emerge using cache or not or portage's work |
15 |
> directory being on tmpfs or not. I don't care if emerge uses cache |
16 |
> DURING the emerge process because it is always enabled in both tests. |
17 |
|
18 |
But you *should* care. If you don't have enough memory, the kernel will |
19 |
reclaim memory from the pagecache, so the whole process rapidity won't |
20 |
only rely on RAM rapidity anymore. |
21 |
|
22 |
> The point is whether portage's work directory is on tmpfs or not makes |
23 |
> emerges faster. |
24 |
> |
25 |
> The thing about what you are saying is that I ran those tests with the |
26 |
> files in memory. What I am saying is this, that is not the case. I am |
27 |
> clearing that memory with the drop_cache command between each test. You |
28 |
> claim that cache is affecting the timing but I am clearing the very same |
29 |
> cache the same as a reboot would. The emerge times whether portage's |
30 |
|
31 |
We do agree with you that you droped the cache between the tests with |
32 |
almost the same effect of a reboot. |
33 |
|
34 |
> The emerge times whether portage's |
35 |
> work directory is on tmpfs or not didn't change enough to make a |
36 |
> difference. |
37 |
|
38 |
Yes, we agree. You droped the cache which is expected to get correct |
39 |
tests. |
40 |
|
41 |
What we are saying is that you droped the cache but did NOT DISABLED the |
42 |
VM caches (kernel cache). You say that you don't care of that one |
43 |
because it was involved in all the tests. We say that you might not care |
44 |
in some contexts, not for all the contexts. You reach the context where |
45 |
it does not matter much, fine. |
46 |
|
47 |
-- |
48 |
Nicolas Sebrecht |