Messages in this thread | | | Date | Mon, 27 Apr 1998 17:24:26 +0200 (MET DST) | From | Rik van Riel <> | Subject | Re: 2.1.98 also corrosive |
| |
On Sun, 26 Apr 1998, Andrea Arcangeli wrote:
> Bill reported that this patch helps in system with tiny memory: > > --- linux/mm/vmscan.c 1998/04/25 14:01:24 1.1 > +++ linux/mm/vmscan.c 1998/04/25 14:03:17 > @@ -580,6 +580,7 @@ > run_task_queue(&tq_disk); > > } > + check_dcache_memory(); > }
The problem probably is that the dcache code changed somewhere. In mm/vmscan.c, in function try_to_free_page(), there is a call being made to shrink_dcache_memory()... Upon checking that function (in fs/dcache.c), I only found a 'fake' function that just increments the 'wanted' counter.
The 'real' shrinking function, check_dcache_memory() is being called from fs/namei.c in the functions __namei() (called from open(), etc...) and open_namei(), so the dcache will only shrink on open()s of files.
The added call from kswapd is, IMHO, a good thing. This is mainly because small-mem machines don't always do enough open()s to recover from a bad case of find...
grtz,
Rik.
PS, this fix really should go in the kernel. +-------------------------------------------+--------------------------+ | Linux: - LinuxHQ MM-patches page | Scouting webmaster | | - kswapd ask-him & complain-to guy | Vries cubscout leader | | http://www.phys.uu.nl/~riel/ | <H.H.vanRiel@phys.uu.nl> | +-------------------------------------------+--------------------------+
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |