Nicolas Sebrecht wrote: > The 06/09/12, Dale wrote: > >> Then take a look at it this way. If I emerge seamonkey with portage's >> work directory on disk and it takes 12 minutes, the first time. Then I >> clear the caches and emerge seamonkey again while portage's work >> directory is on tmpfs and it is 12 minutes. Then repeat that process a >> few times more. If the outcome of all those emerges is 12 minutes, >> regardless of the order, then putting portages work directory on tmpfs >> makes no difference at all in that case. > We fully agree with you, here. >
That's good. >> The emerge times are exactly >> the same regardless of emerge using cache or not or portage's work >> directory being on tmpfs or not. I don't care if emerge uses cache >> DURING the emerge process because it is always enabled in both tests. > But you *should* care. If you don't have enough memory, the kernel will > reclaim memory from the pagecache, so the whole process rapidity won't > only rely on RAM rapidity anymore. But if you are going to use tmpfs, you have to have the memory available. It doesn't matter if it is tmpfs or just used in the normal way. That is my point. >> The point is whether portage's work directory is on tmpfs or not makes >> emerges faster. >> >> The thing about what you are saying is that I ran those tests with the >> files in memory. What I am saying is this, that is not the case. I am >> clearing that memory with the drop_cache command between each test. You >> claim that cache is affecting the timing but I am clearing the very same >> cache the same as a reboot would. The emerge times whether portage's > We do agree with you that you droped the cache between the tests with > almost the same effect of a reboot. That's good. >> The emerge times whether portage's >> work directory is on tmpfs or not didn't change enough to make a >> difference. > Yes, we agree. You droped the cache which is expected to get correct > tests. > > What we are saying is that you droped the cache but did NOT DISABLED the > VM caches (kernel cache). You say that you don't care of that one > because it was involved in all the tests. We say that you might not care > in some contexts, not for all the contexts. You reach the context where > it does not matter much, fine. > Who doing a normal update would cut off the cache? I wouldn't. I know how to clear it but I don't know how to disable it nor would I or most likely anyone else in normal use. The point of my test was in a normal use case of emerge with or without tmpfs and if there is any difference in the emerge times. There wasn't. Once emerge starts and loads all the stuff it needs, tmpfs doesn't matter at that point. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
