From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20031010 Mozilla Firebird/0.6.1 Description of problem: Buffers cached in 2.4.19-pre10-ac2 (the base of the as2.1 kernels) remain in memory, even when heavy pressure is applied to evict and replace them. This was originally noticed on ia64, but the issue is also demonstrable on x86 AS2.1. The problem doesn't exist in 2.4.18, 2.4.19-pre10, but does exist in 2.4.19-pre10-ac2. Version-Release number of selected component (if applicable): kernel-smp-2.4.18-e.37 How reproducible: Always Steps to Reproduce: 1. freshly reboot a system 2. time a dd of a large file ("a")to /dev/null (large enough to fill buffer cache) 3. time a dd of an equally large file ("b") to /dev/null one or more times 4. time a dd of "b" again, noting that the time stays consistent with the first dd of "b" 5. dd "a" again, noting that it is still faster, indicating it is stil l cached Actual Results: reading file "a" continues to be faster than reading file "b", even when read immediately after "b". Expected Results: the contents of file "a" should be evicted from buffer cache after "b" is read in, making consectuve "b" reads faster. Additional info: I'll attach my numbers from my ia64 tests, but I also ran some tests on an x86 box to show that it doesn't appear to be arch specific. Here are the results of some tests on an x86 box, running AS2.1. This box is a Compaq dl360g2 with 2GB of ram. The kernels are not patched beyond what is noted, and the config used was generated by running make oldconfig, starting w/ the AS2.1 config. Baseline - fresh boot, 2.4.18 ----------------------------- 1.8G: 1m8.771s 1.8G: 0m2.260s 1.8G: 0m9.113s 1.8G: 0m9.113s Test2 - fresh boot, 2.4.18 -------------------------- 1.8G: 1m14.203s 1.8G-2: 1m11.501s 1.8G-2: 1m12.558s 1.8G-2: 1m17.026s 1.8G-2: 0m56.461s 1.8G: 1m14.859s The first file appears to have been evicted (although it didn't seem to help much w/ 1.8G-2.) Test3 - fresh boot, 2.4.19-pre10 -------------------------------- 1.8G: 1m7.764s 1.8G-2: 1m4.309s 1.8G-2: 0m9.139s 1.8G-2: 0m9.077s 1.8G-2: 0m9.033s 1.8G: 0m58.353s 1.8G was evicted right off, and 1.8G-2 quickly became cached. This seems like the desired effect. Test4 - fresh boot, 2.4.19-pre10-ac2 ------------------------------------ 1.8G: 1m9.905s 1.8G-2: 1m11.321s 1.8G-2: 1m7.586s 1.8G-2: 1m7.775s 1.8G-2: 1m8.924s 1.8G: 0m48.826s 1.8G appears to remain in buffer cache, at least partially - 1.8G-2 doesn't appear to ever make it into cache.
Created attachment 95812 [details] ia64 experiments Comparison of the e37 kernel vs. an almost-vanilla 2.4.18 & 2.4.19 (kernel.org + ia64 patch + various bits needed to boot). Given that its easy to boot/run experiments on vanilla kernel.org 2.4s on x86, those numbers (in the initial report) are probably more useful.
note that AS2.1 x86 is a 2.4.9 based kerenl...did you really test that kernel? Also, i coulnd't read the attachment...
> note that AS2.1 x86 is a 2.4.9 based kerenl...did you really test that > kernel? No - and I apologize for not making that obvious. I should have modified my statement to say x86 as2.1 w/ a 2.4.19-pre10-ac2 kernel. To be clear - I'm asserting this is a problem w/ as2.1 ia64, not on as2.1 x86. The x86 test results are there to demonstrate that 1) the issue first appears with the application of the ac2 patch and 2) the issue is likely not caused by the arch specific code. > Also, i coulnd't read the attachment... I downloaded a copy from bugzilla & it works fine for me in gnumeric 1.0.8. I also had gnumeric export it as html (and it is surprisingly readable): http://free.linux.external.hp.com/~dannf/rh-109466-bufcache.html
Interesting issue, but its not clear this is causing any serious problems.