Date: Sun, 31 Jan 2010 09:34:09 +0100
From: Andi Kleen <andi@firstfloor.org>
To: tytso@mit.edu, Christoph Lameter <cl@linux-foundation.org>,
       Andi Kleen <andi@firstfloor.org>, Dave Chinner <david@fromorbit.com>,
       Miklos Szeredi <miklos@szeredi.hu>,
       Alexander Viro <viro@ftp.linux.org.uk>,
       Christoph Hellwig <hch@infradead.org>,
       Christoph Lameter <clameter@sgi.com>, Rik van Riel <riel@redhat.com>,
       Pekka Enberg <penberg@cs.helsinki.fi>, akpm@linux-foundation.org,
       Nick Piggin <nickpiggin@yahoo.com.au>, Hugh Dickins <hugh@veritas.com>,
       linux-kernel@vger.kernel.org
Subject: Re: inodes: Support generic defragmentation
Message-ID: <20100131083409.GF29555@one.firstfloor.org>
References: <20100129204931.789743493@quilx.com> <20100129205004.405949705@quilx.com> <20100130192623.GE788@thunk.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100130192623.GE788@thunk.org>
User-Agent: Mutt/1.4.2.2i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1466
Lines: 36

On Sat, Jan 30, 2010 at 02:26:23PM -0500, tytso@mit.edu wrote:
> On Fri, Jan 29, 2010 at 02:49:42PM -0600, Christoph Lameter wrote:
> > This implements the ability to remove inodes in a particular slab
> > from inode caches. In order to remove an inode we may have to write out
> > the pages of an inode, the inode itself and remove the dentries referring
> > to the node.
> 
> How often is this going to happen?  Removing an inode is an incredibly

The standard case is the classic updatedb. Lots of dentries/inodes cached
with no or little corresponding data cache.

> a huge number of pages that are actively getting used, the thrashing
> that is going to result is going to enormous.

I think the consensus so far is to try to avoid any inodes/dentries
which are dirty or used in any way.

I personally would prefer it to be more aggressive for memory offlining
though for RAS purposes though, but just handling the unused cases is a 
good first step.

> "invalidate_mapping_pages() will not block on I/O activity, and it
> will refuse to invalidate pages which are dirty, locked, under
> writeback, or mapped into page tables."

I think that was the point.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.
--
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/