Messages in this thread | | | Date | Thu, 26 Apr 2007 17:22:15 +1000 | From | Nick Piggin <> | Subject | Re: [00/17] Large Blocksize Support V3 |
| |
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 >>another? > > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |