Bug 52374 - Kernel doesn't automatically purge inode and dentry cache entries
Summary: Kernel doesn't automatically purge inode and dentry cache entries
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
URL:
Whiteboard:
: 52427 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-23 08:29 UTC by Phil Knirsch
Modified: 2015-03-05 01:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-08-24 17:15:28 UTC
Embargoed:


Attachments (Terms of Use)

Description Phil Knirsch 2001-08-23 08:29:08 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010725

Description of problem:
Each morning when i come to the office my box is dead slow due to the fact
that it allocated literally more than 100 000 inode and dentry caches over
night and even swapped out running but unused applications for these caches.

In order to get the machine back to an usable state i need to switch
desktops and stop and start all big applications in order to purge the
cache entries. It takes on my pretty fast Athlon 900 box with a very fast
IBM drive about 20-30 seconds. I imagine this is much worse on slower machines.

This problem might be related to the ones other people have reported about
machines slowing down considerably and the need to restart X (which
effectively does the same as i do manually, namely stop and start all
important applications thereby puring the caches).
The whole effect can directly be reproduce easily by running X11 and then
doing a kernel rpm rebuild and an updatedb at the same time.

If you don't switch desktops during that time you can watch how the cache
entries eat up all available physical memory and swap out big applications
like mozilla.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Start X11 (Gnome or KDE)
2. Rebuild kernel and run updatedb. Don't switch desktops
3. Watch the cache entries climb to unheard of hights.
	

Actual Results:  The cache entries fill up massively and i need to take the
steps described above to the get system back to a usable state.

Expected Results:  There are basically 2 resolutions:

1) The cache entries should never ever requires processes to be swapped
out. This would be optimal for desktop systems, but maybe not for server
systems.
2) The other good solution would be to let the kernel check in regular
intervals (somewhere between 1 minute and 1 hour) which cache entries have
been used and to purge the oldest ones that have not been used in the given
interval. That would still allow the cache entries to be used optimally on
server systems while still giving good desktop performance.

Additional info:

Comment 1 Glen Foster 2001-08-24 17:09:20 UTC
This defect is considered SHOULD-FIX for Fairfax.

Comment 2 Arjan van de Ven 2001-08-24 17:13:26 UTC
Please test kernels 2.4.7-2.7 or later; they have code to fix this and I'd
appreciate testers of this

Comment 3 Arjan van de Ven 2001-08-24 17:15:23 UTC
*** Bug 52427 has been marked as a duplicate of this bug. ***


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