On Wed, 12 Sep 2007, Nick Piggin wrote:

quoted text
> I will still argue that my approach is the better technical solution for large
> block support than yours, I don't think we made progress on that. And I'm
> quite sure we agreed at the VM summit not to rely on your patches for
> VM or IO scalability.

The approach has already been tried (see the XFS layer) and found lacking. 

Having a fake linear block through vmalloc means that a special software 
layer must be introduced and we may face special casing in the block / fs 
layer to check if we have one of these strange vmalloc blocks.

quoted text
> But you just showed in two emails that you don't understand what the
> problem is. To reiterate: lumpy reclaim does *not* invalidate my formulae;
> and antifrag does *not* isolate the issue.

I do understand what the problem is. I just do not get what your problem 
with this is and why you have this drive to demand perfection. We are 
working a variety of approaches on the (potential) issue but you 
categorically state that it cannot be solved.

quoted text
> But what do you say about viable alternatives that do not have to
> worry about these "unlikely scenarios", full stop? So, why should we
> not use fs block for higher order page support?

Because it has already been rejected in another form and adds more 
layering to the filesystem and more checking for special cases in which 
we only have virtual linearity? It does not reduce the number of page 
structs that have to be handled by the lower layers etc.

Maybe we coud get to something like a hybrid that avoids some of these 
issues? Add support so something like a virtual compound page can be 
handled transparently in the filesystem layer with special casing if 
such a beast reaches the block layer?

quoted text
> I didn't skip that. We have large page pools today. How does that give
> first class of support to those allocations if you have to have memory
> reserves?

See my other mail. That portion is not complete yet. Sorry.
-
unsubscribe notice
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/