From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 23 May 2007 12:15:16 -0700 (PDT) From: Christoph Lameter Subject: Re: [patch 1/3] slob: rework freelist handling In-Reply-To: <20070523183224.GD11115@waste.org> Message-ID: References: <20070523050333.GB29045@wotan.suse.de> <20070523051152.GC29045@wotan.suse.de> <20070523052206.GD29045@wotan.suse.de> <20070523061702.GA9449@wotan.suse.de> <20070523071200.GB9449@wotan.suse.de> <20070523183224.GD11115@waste.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Matt Mackall Cc: Nick Piggin , Andrew Morton , Linux Memory Management List List-ID: On Wed, 23 May 2007, Matt Mackall wrote: > You keep saying something like this but I'm never quite clear what you > mean. There are no slabs so reclaiming unused slabs is a non-issue. > Things like shrinking the dcache should work: > > __alloc_pages > try_to_free_pages > shrink_slab > shrink_dcache_memory > > I don't see any checks of ZVCs interfering with that path. One example is the NR_SLAB_RECLAIMABLE ZVC. SLOB does not handle it thus it is always zero. slab reclaim is entered in mm/vsmscan shrink_all_memory(): nr_slab = global_page_state(NR_SLAB_RECLAIMABLE); /* If slab caches are huge, it's better to hit them first */ while (nr_slab >= lru_pages) { reclaim_state.reclaimed_slab = 0; shrink_slab(nr_pages, sc.gfp_mask, lru_pages); if (!reclaim_state.reclaimed_slab) nr_slab will always be zero. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org