Nicolas Sebrecht wrote: > 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.
I do get it. I CLEARED #1 and #2, there is no usage of #3 and #4 is not large enough here to matter. So, it is left with #5. See the point? The test was a NORMAL emerge with portages work directory on tmpfs and a NORMAL emerge with portages work directory on disk and compare the results. The test resulted in little if any difference. If I ran the test and did not clear the cache, then I would expect skewed results because after the first emerge, some files would be cached in ram and the drive would not be used. If you clear the cache, then it has to take the same steps regardless of whether it was run first, second or third time. > > 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. > But if you CLEAR the kernel cache between each test, then it doesn't matter either. I am clearing the KERNEL cache which includes pagecache, dentries and inodes. I can see the difference in gkrellm, top and in what the command free gives me. Put another way. I run a emerge on tmpfs and note the emerge times. I reboot. I run the same emerge again with it not on tmpfs. Do we agree that that would result in a actual real result? If yes then using the command to clear the cache is the same as rebooting. It's the whole point of having the feature in the kernel. The file drop_caches when set to 3 with the echo command erases, deletes or whatever you want to call it, the caches. That's from the kernel folks as linked to in another reply. That's not me saying it, it is the kernel folks saying it. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
