1 |
Nicolas Sebrecht wrote: |
2 |
> The 06/09/12, Dale wrote: |
3 |
> |
4 |
>> Then take a look at it this way. If I emerge seamonkey with portage's |
5 |
>> work directory on disk and it takes 12 minutes, the first time. Then I |
6 |
>> clear the caches and emerge seamonkey again while portage's work |
7 |
>> directory is on tmpfs and it is 12 minutes. Then repeat that process a |
8 |
>> few times more. If the outcome of all those emerges is 12 minutes, |
9 |
>> regardless of the order, then putting portages work directory on tmpfs |
10 |
>> makes no difference at all in that case. |
11 |
> We fully agree with you, here. |
12 |
> |
13 |
|
14 |
That's good. |
15 |
|
16 |
|
17 |
>> The emerge times are exactly |
18 |
>> the same regardless of emerge using cache or not or portage's work |
19 |
>> directory being on tmpfs or not. I don't care if emerge uses cache |
20 |
>> DURING the emerge process because it is always enabled in both tests. |
21 |
> But you *should* care. If you don't have enough memory, the kernel will |
22 |
> reclaim memory from the pagecache, so the whole process rapidity won't |
23 |
> only rely on RAM rapidity anymore. |
24 |
|
25 |
But if you are going to use tmpfs, you have to have the memory |
26 |
available. It doesn't matter if it is tmpfs or just used in the normal |
27 |
way. That is my point. |
28 |
|
29 |
>> The point is whether portage's work directory is on tmpfs or not makes |
30 |
>> emerges faster. |
31 |
>> |
32 |
>> The thing about what you are saying is that I ran those tests with the |
33 |
>> files in memory. What I am saying is this, that is not the case. I am |
34 |
>> clearing that memory with the drop_cache command between each test. You |
35 |
>> claim that cache is affecting the timing but I am clearing the very same |
36 |
>> cache the same as a reboot would. The emerge times whether portage's |
37 |
> We do agree with you that you droped the cache between the tests with |
38 |
> almost the same effect of a reboot. |
39 |
|
40 |
That's good. |
41 |
|
42 |
>> The emerge times whether portage's |
43 |
>> work directory is on tmpfs or not didn't change enough to make a |
44 |
>> difference. |
45 |
> Yes, we agree. You droped the cache which is expected to get correct |
46 |
> tests. |
47 |
> |
48 |
> What we are saying is that you droped the cache but did NOT DISABLED the |
49 |
> VM caches (kernel cache). You say that you don't care of that one |
50 |
> because it was involved in all the tests. We say that you might not care |
51 |
> in some contexts, not for all the contexts. You reach the context where |
52 |
> it does not matter much, fine. |
53 |
> |
54 |
|
55 |
Who doing a normal update would cut off the cache? I wouldn't. I know |
56 |
how to clear it but I don't know how to disable it nor would I or most |
57 |
likely anyone else in normal use. The point of my test was in a normal |
58 |
use case of emerge with or without tmpfs and if there is any difference |
59 |
in the emerge times. There wasn't. Once emerge starts and loads all |
60 |
the stuff it needs, tmpfs doesn't matter at that point. |
61 |
|
62 |
Dale |
63 |
|
64 |
:-) :-) |
65 |
|
66 |
-- |
67 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |