Re: inodes: Support generic defragmentation

[Andi Kleen <andi@firstfloor.org>]

On Mon, Feb 01, 2010 at 08:47:39AM -0500, tytso@mit.edu wrote:
> On Mon, Feb 01, 2010 at 11:17:02AM +0100, Andi Kleen wrote:
> > 
> > On the other hand I would like to keep the option to be more aggressive
> > for soft page offlining where it's useful and nobody cares about 
> > the cost.
> 
> I'm not sure I understand what the goals are for "soft page
> offlining".  Can you say a bit more about that?

Predictive offlining of memory pages based on corrected error counts.
This is a useful feature to get more out of lower quality (and even
high quality) DIMMs.

This is already implemented in mcelog+.33ish memory-failure.c, but right
now it's quite dumb when trying to free a dcache/inode page (it basically
always has to blow away everything)

Also this is just one use case for this. The other would be 2MB
page at runtime support by doing targetted freeing (would be especially
useful with the upcoming transparent huge pages). Probably others
too. I merely mostly quoted hwpoison because I happen to work on that.

> 
> > Or the "let's add a updatedb" hint approach has the problem that
> > it won't cover a lot of other programs (as Linus always points out
> > these new interfaces rarely actually get used)
> 
> Sure, but the number of programs that scan all of the files in a file
> system and would need this sort of hint are actually pretty small.

Not sure that's true.

Also consider a file server :- how would you get that hint from the 
clients?

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.