On Thu, Sep 6, 2012 at 10:07 AM, Dale <rdalek1...@gmail.com> wrote: > 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.
Dale, here's what you're missing: emerge first downloads the source tarball and drops it on disk. Once the tarball has been placed on disk, the time required to read the tarball back into memory is negligible; it's a streamed format. The next step is what's important: the tarball gets extracted into PORTAGE_TEMP. At that moment onward, all the files that were inside that tarball are in your file cache until something bumps it out. If you have enough RAM, then the file will not be bumped out as a consequence of build-time memory usage. As a consequence, if you have enough ram, you won't see much (if any) difference in build times if you're comparing tmpfs to a normal filesystem...which means tmpfs (for you) won't have any benefit beyond being self-cleaning on a reboot or remount. So your drop_cache has no influence over build times, since the only cache behavior that matters is whatever happens between the time emerge unpacks the tarball and the time emerge exits. To see the difference, try something like "watch drop_cache" leave that running while you let a few builds fly. You should see an increase in build times. -- :wq
