Nicolas Sebrecht wrote: > The 06/09/12, Dale wrote: > >> Then explain to me why it was at times slower while on tmpfs? Trust me, >> I ran this test many times and in different orders and it did NOT make >> much if any difference. > As explained, this is expected if you have enough RAM. > > I didn't check but I would expect that files stored in tmpfs are NOT > duplicated in the the kernel cache in order to save RAM. So, the > different times could come from the fact that the kernel will first look > up in the kernel cache and /then/ look up in the tmpfs. > > In the scenario without tmpfs and lot of RAM, every unpacked file is > stored in the _kernel cache_ with really fast access much before hitting > the disk or even the disk cache (RAM speed and very few processor > calculation required). While retrieving, the file is found on first look > up from the kernel cache.
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. > > In the other scenario with tmpfs and lot of RAM, every unpacked file is > stored in the tmpfs allowing very fast access (due to RAM speed) but > with the price of a first negative result from the kernel cache (and > perhaps additional time needed by the kernel for accessing the file > through the driver of the tmpfs filesystem). > > Using tmpfs will still be better as it prevents from writes to the disk > in the spare times, avoiding unnecessary mecanic movements and saving > disk life time. The thing is, this was tested because people wanted to see what the improvements was. When tested, it turned out that there was very little if any difference. 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. >> I might add, the cache on the drive I was using is nowhere near large >> enough to cache the tarball for the package. Heck, the cache on my >> current system drive is only 8Mbs according to hdparm. That is not much >> since I tested using much larger packages. You can't cache files larger >> than the cache. > The disk cache is out of the scope. True, just wanted to make sure we were talking about the same cache here. > >> Do I need to run a test, reboot, run the test again to show this is not >> making much if any difference? I mean, really? o_O > It won't make any difference from the drop cache configuration but it is > still not the point! > 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. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
