Michael Mol wrote: > 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. >
But this is what you guys are missing too. If you want to use tmpfs, you have to have enough ram to begin with. Whether you use tmpfs or not, you have to have enough ram to do the compile otherwise you start using swap or it just crashes. Having ram is a prerequisite to using tmpfs. You can't set tmpfs to 8Gbs on a machine that doesn't have 8Gbs available and it work. I don't count swap because when you start using swap, it all goes out the window at that point. There is another flaw in your assumption above. I already had the tarballs downloaded BEFORE even the first emerge. I may not be the sharpest tool in the shed but I do know to download first when trying to measure a emerge time. I can measure my DSL speed with other tools. lol What the people wanted to test is if putting portages work directory on tmpfs would make emerge times faster. It doesn't. The posts people make admit to that fact now but want to argue the reason. I don't care about the reason. I just know that it doesn't matter. Putting portage's work directory on tmpfs does NOT make it faster. For the purpose of this thread, it would be a good idea to save wear and tear on the SSD but one should not expect compile times to improve as one would expect. I might also add, I didn't always have 16Gbs on this rig. I started with 4Gbs. Then I went to 8 and later on went to 16Gbs. Do we all admit that having portage on tmpfs does not make emerge times faster yet? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
