Re: [00/17] Large Blocksize Support V3

From: Nick Piggin
Date: Thu Apr 26 2007 - 03:22:40 EST

Christoph Lameter wrote:
On Thu, 26 Apr 2007, Nick Piggin wrote:

Right and we need to create series of other approaches that we then label
"non-hack" to replace it.

I don't understand? We're talking about several utterly different designs
to approach these problems. You don't agree that one might be better than

What I seeing is a series of approaches being put into the kernel to address this issue. We already have the lumpy reclaim there. Then we talk about other fixed to basic page handling in the kernel to make it better.
Now you want yet another fs layer. All of that could be taken care of by

No I don't want to add another fs layer.

a defrag approach with larger pages. This has been done a number of times before and actually the large page approach is a textbook example on how to improve performance. It goes waaaay back.

I still don't think anti fragmentation or defragmentation are a good
approach, when you consider the alternatives.

It is like Linus on the page colouring issue. That goes back a looong
way too, but that doesn't mean it is the right way to do it.

The code paths can stay the same. You can switch CONFIG_LARGE pages off
if you do not want it and it is as it was.

That isn't a good reason to merge something. If you don't have numbers then
that just seems incredible.

Dont worry you will get numbers... Just did not have time to fix the bug in this one since I had to take care of something else.

OK, I would like to see them. And also discussions of things like why
we shouldn't increase PAGE_SIZE instead.

SUSE Labs, Novell Inc.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at