Bug 109466 - buffer cache failing to evict
Summary: buffer cache failing to evict
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel
Version: 2.1
Hardware: ia64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Baron
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-11-08 02:15 UTC by dann frazier
Modified: 2013-03-06 05:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-18 02:58:16 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
ia64 experiments (7.37 KB, application/x-gnumeric)
2003-11-08 02:24 UTC, dann frazier
no flags Details

Description dann frazier 2003-11-08 02:15:10 UTC
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.

Comment 1 dann frazier 2003-11-08 02:24:48 UTC
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.

Comment 2 Jason Baron 2003-11-10 19:09:16 UTC
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...

Comment 3 dann frazier 2003-11-10 20:43:03 UTC
> 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

Comment 7 Jason Baron 2004-11-18 02:58:16 UTC
Interesting issue, but its not clear this is causing any serious problems.


Note You need to log in before you can comment on or make changes to this bug.