[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1002041109500.28165@router.home>
Date: Thu, 4 Feb 2010 11:13:15 -0600 (CST)
From: Christoph Lameter <cl@...ux-foundation.org>
To: Nick Piggin <npiggin@...e.de>
cc: Dave Chinner <david@...morbit.com>, tytso@....edu,
Andi Kleen <andi@...stfloor.org>,
Miklos Szeredi <miklos@...redi.hu>,
Alexander Viro <viro@....linux.org.uk>,
Christoph Hellwig <hch@...radead.org>,
Christoph Lameter <clameter@....com>,
Rik van Riel <riel@...hat.com>,
Pekka Enberg <penberg@...helsinki.fi>,
akpm@...ux-foundation.org, Nick Piggin <nickpiggin@...oo.com.au>,
Hugh Dickins <hugh@...itas.com>, linux-kernel@...r.kernel.org
Subject: Re: inodes: Support generic defragmentation
On Thu, 4 Feb 2010, Nick Piggin wrote:
> Well what I described is to do the slab pinning from the reclaim path
> (rather than from slab calling into the subsystem). All slab locking
> basically "innermost", so you can pretty much poke the slab layer as
> much as you like from the subsystem.
Reclaim/defrag is called from the reclaim path (of the VM). We could
enable a call from the fs reclaim code into the slab. But how would this
work?
> After that, LRU on slabs should be fairly easy. Slab could provide a
> private per-slab pointer for example that is managed by the caller.
> Subsystem can then call into slab to find the objects.
Sure with some minor changes we could have a call that is giving you the
list of neighboring objects in a slab, while locking it? Then you can look
at the objects and decide which ones can be tossed and then do another
call to release the objects and unlock the slab.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists