The 06/09/12, Dale wrote:

> The point you are missing is this.  Between those tests, I CLEARED that
> cache.  The thing you and Neil claim that makes a difference does not
> exist after you clear the cache.  I CLEARED that cache between EACH and
> every test that was ran whether using tmpfs or not.  I did this instead
> of rebooting my system after each test. 

We clearly understand that you cleared the cache between the tests. We
pretend that it is not much relevant for your tests because of another
process.

>                     So, in theory I would say that using tmpfs would
> result in faster compile times.  After testing, theory left the building
> and reality showed that it did not make much if any difference. 

Yes, because you did the tests on a system with lot of RAM.

If the kernel needs to retrieve a file, there is basically the following
workflow:

1. retrieve file from kernel cache;
2. if not found, retrieve file from tmpfs cache;
3. if not found, retrieve file from swap cache;
4. if not found, retrieve file from disk cache;
5. if not found, retrieve file from disk.

This is simplified workflow but you get the idea.

Now, what we are saying is that *when you have lot of RAM*, the kernel
never hit 2, 3, 4 and 5. The problem with the kernel cache is that files
stored in this cache are dropped from it very fast. tmpfs allows to have
better files persistence in RAM. But if you have lot of RAM, the files
stored in the kernel cache are /not/ dropped from it which allows the
kernel to work with files in RAM only.

Clearing the kernel cache between the tests does not change much since
files are stored in RAM again, at the unpack process time. What makes
compilation very slow from the disk are all the _next reads and writes_
required by the compilation.

> Well, why say that caching makes a difference then say it doesn't matter
> when those caches are cleared?  Either caches matter or it doesn't. 

It does make a difference if you don't have enough RAM for the kernel
cache to store all the files involved in the whole emerge process and
every other process run by the kernel during the emerge.

-- 
Nicolas Sebrecht

Reply via email to