Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
From: Mel Gorman (mel_at_csn.ul.ie)
Date: 11/04/05
- Previous message: Arun Sharma (अरुण): "IPC_STAT and SHM_HUGETLB"
- In reply to: Nick Piggin: "Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19"
- Next in thread: Paul Mackerras: "Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 4 Nov 2005 02:35:09 +0000 (GMT) To: Nick Piggin <nickpiggin@yahoo.com.au>
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/
- Previous message: Arun Sharma (अरुण): "IPC_STAT and SHM_HUGETLB"
- In reply to: Nick Piggin: "Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19"
- Next in thread: Paul Mackerras: "Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
