Red Hat Bugzilla – Bug 109466
buffer cache failing to evict
Last modified: 2013-03-06 00:56:17 EST
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
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,
does exist in 2.4.19-pre10-ac2.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. freshly reboot a system
2. time a dd of a large file ("a")to /dev/null (large enough to fill
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
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.
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
Test2 - fresh boot, 2.4.18
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 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 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]
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
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
Interesting issue, but its not clear this is causing any serious problems.