Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755443AbYJTUu7 (ORCPT ); Mon, 20 Oct 2008 16:50:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752571AbYJTUut (ORCPT ); Mon, 20 Oct 2008 16:50:49 -0400 Received: from fxip-0047f.externet.hu ([88.209.222.127]:44096 "EHLO pomaz-ex.szeredi.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752322AbYJTUus (ORCPT ); Mon, 20 Oct 2008 16:50:48 -0400 To: cl@linux-foundation.org CC: miklos@szeredi.hu, penberg@cs.helsinki.fi, nickpiggin@yahoo.com.au, hugh@veritas.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org In-reply-to: <48FCE1C4.20807@linux-foundation.org> (message from Christoph Lameter on Mon, 20 Oct 2008 14:53:40 -0500) Subject: Re: SLUB defrag pull request? References: <1223883004.31587.15.camel@penberg-laptop> <1223883164.31587.16.camel@penberg-laptop> <200810132354.30789.nickpiggin@yahoo.com.au> <48F378C6.7030206@linux-foundation.org> <48FC9CCC.3040006@linux-foundation.org> <48FCCC72.5020202@linux-foundation.org> <48FCD7CB.4060505@linux-foundation.org> <48FCE1C4.20807@linux-foundation.org> Message-Id: From: Miklos Szeredi Date: Mon, 20 Oct 2008 22:50:30 +0200 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1793 Lines: 41 On Mon, 20 Oct 2008, Christoph Lameter wrote: > Miklos Szeredi wrote: > > So, isn't it possible to do without get_dentries()? What's the > > fundamental difference between this and regular cache shrinking? > > The fundamental difference is that slab defrag operates on sparsely > populated dentries. It comes into effect when the density of > dentries per page is low and lots of memory is wasted. It > defragments by kicking out dentries in low density pages. These can > then be reclaimed. OK, but why can't this be done in just one stage? AFAICS the problem is exactly the same as generic shrinking, except it wants to evict dentries selectively: only ones which are in very sparse slabs. So is the problem selecting these dentries? Would it be too expensive to do it the same as normal cache shrinking and walk the lru, but only evict the ones which are tagged as being in a sparse page? > The dentries that we get a ref on are candidates for removal. Their > lifetime is limited. Unmounting while we are trying to remove > dentries/inodes results in two mechanisms removing dentries/inodes. > > If we have obtained a reference then invalidate_list() will return > the number of busy inodes which would trigger the printk in > generic_shutdown_super(). But these are inodes currently being > reclaimed by slab defrag. Just waiting a bit would remedy the > situation. I guess so, but that's just a hack to work around the problem, and creates more interdependencies between VFS and the allocator with unforseeable consequences. Miklos -- 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/