Messages in this thread | | | Date | Fri, 4 Nov 2005 02:35:09 +0000 (GMT) | From | Mel Gorman <> | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 |
| |
On Fri, 4 Nov 2005, Nick Piggin wrote:
> Mel Gorman wrote: > > On Fri, 4 Nov 2005, Nick Piggin wrote: > > > > Todays massive machines are tomorrows desktop. Weak comment, I know, but > > it's happened before. > > > > Oh I wouldn't bet against it. And if desktops of the future are using > 100s of GB then they probably would be happy to use 64K pages as well. >
And would it not be nice to be ready when it happens, before it happens even?
> > > > > Maybe the solution is to bloat the kernel sources enough to make > > > 64KB pages worthwhile? > > > > > > > Sorry this wasn't meant to be a dig at your patches - I guess it turned > out that way though :\ >
Oh, I'll live. If I was going to take it personally and go into a big sulk, I wouldn't be here. This is linux-kernel, not the super-friends club.
> But yes, if anybody is adding complexity or size to core code it > obviously does need to be justified -- and by no means does this only > apply to you. >
I've tried to justify it with benchmarks that came with each release and code reviews, particularly by Dave Hansen, showed that earlier versions had significant problems that needed to be ironed out. I don't want to hurt the normal case, because the fact of the matter is, my desktop machine (which runs with these patches to see if there are any bugs) runs the normal case and it will until we get much further because I'm not configuring my machine for HugeTLB when it boots. If I'm hurting the normal case, that's more time switching windows to see if the next test kernel has built yet.
If we can do this and not regress in the standard case, then what is wrong? I'm still waiting for figures that say this approach is slow and I can only assume someone is trying considering the length of this thread. If and when those figures show up, I'll put on the thinking hat and see where I went wrong because regression performance is wrong. There is a win-win solution somewhere, how hard could it possibly be :) ?
I'm looking at the zone approach. I want to see if it can work in a nice fashion, not in a "if the sysadm can see the future and configure correctly, it'll work just fine" fashion. I'm not confident, but it might be bias.
-- Mel Gorman Part-time Phd Student Java Applications Developer University of Limerick IBM Dublin Software Lab - 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/
| |