Messages in this thread | | | Date | Tue, 27 Apr 2004 14:17:53 +1000 | From | Nick Piggin <> | Subject | Re: ext3 inode cache eats system, news at 11 |
| |
Andrew Morton wrote: > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > >> Andrew Morton wrote: >> >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc2/2.6.6-rc2-mm2/broken-out/slab-order-0-for-vfs-caches.patch >> > >> > is not a completely happy solution, but it should fix things up. >> >> Another thing you could be doing is not zeroing swapper->nr >> if the shrinker function doesn't do anything, in order to try >> to maintain pressure on the dcache. This would be similar to >> your deferred list idea. > > > Am now doing this. > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc2/2.6.6-rc2-mm2/broken-out/shrink_slab-handle-GFP_NOFS.patch >
Ahh good. You may want to subtract the pending ->nr from "(*shrinker->shrinker)(0, gfp_mask)" though, when calculating the size of the next delta to scan.
Well possibly not. The math in your patch presently assumes no entries will be freed due to the built up deferred scanning, and if you changed it to the above idea, it would assume all entries will be freed. I just think it would be good to dampen the increase to ->nr a bit. It would inherently limit ->nr from wrapping too. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |