Neil Bothwick wrote: > On Thu, 06 Sep 2012 07:48:59 -0500, Dale wrote: > >> I don't think that is correct. I am clearing the files in ram. That's >> the point of drop_caches is to clear the kernels cache files. See post >> to Nicolas Sebrecht a bit ago. > Take a step back Dale and read the posts again. This is not about the > state of the cache at the start of the emerge but during it. You may > clear the cache before starting, but that doesn't stop is filling up > again as soon as the emerge reaches src_unpack(). > > This has nothing to do with caching the data from the previous emerge > run, it is all from the currently running emerge. You may think you are > unpacking the tarball to disk and then loading those files into the > compiler, but you are only using the copies that are cached when you > unpack. > >
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. 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. 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 work directory is on tmpfs or not didn't change enough to make a difference. That is what I am saying the tests resulted in. It was not what I expected but it is what I got. It is also what others got as well. I provided a link to the information that should be as clear as it gets. Can you provide a link that shows that the command does not clear the kernel cache? I'm going by what I linked to on kernel.org. Since they are the ones that make the kernels, I think they should know what it is and what it does. Here is some more links with the same info really: http://linux-mm.org/Drop_Caches http://www.linuxinsight.com/proc_sys_vm_drop_caches.html http://bjdean.id.au/wiki/LinuxMemoryManagement Those are all the first links in a google search for "drop_caches kernel". See if you can find anything that says otherwise. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
