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. 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. > 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. > 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! -- Nicolas Sebrecht
