Re: NUMA mempolicy /proc code in mainline shouldn't have been merged

[Andrew Morton <akpm@osdl.org>]

Andi Kleen <ak@suse.de> wrote:
>
> On Monday 19 September 2005 23:32, Christoph Lameter wrote:
> > On Mon, 19 Sep 2005, Andi Kleen wrote:
> > > On Mon, Sep 19, 2005 at 10:11:20AM -0700, Christoph Lameter wrote:
> > > > However, one still does not know which memory section (vma) is
> > > > allocated on which nodes. And this may be important since critical data
> > > > may need to
> > >
> > > Maybe. Well sure of things could be maybe important. Or maybe not.
> > > Doesn't seem like a particularly strong case to add a lot of ugly
> > > code though.
> >
> > We gradually need to fix the deficiencies of the policy layer. Calling
> > fixes "ugly code" and refusing to discuss solutions does not help anyone.
> 
> I'm happy to discuss solutions given a clear use case what you want
> to do, why you want to do it etc. 

Yes.  A clear explanation of the requirements and usecases based on
real-world experience from real-world users and/or application developers. 
I asked Christoph for that last week.  The answers were, iirc, a bit
half-baked, but believeable.

> > Have you ever had the challenge to work with large HPC applications on a
> > large NUMA system? 
> 
> Ah - my code is better because my credentials are better.

No fair.  I've never worked on big HPC systems and any feedback from the
field which Christoph can provide is really important in helping us
understand what features the kernel needs to offer.  I would expect that
SGI engineering have a better understanding of HPC users' needs than pretty
much anyone else in the world.

It's a shame that SGI engineering aren't better at communicating those
needs to wee little kernel developers.  And we need to get better at this
because, as you say, external policy control is going to be a ton harder to
swallow than /proc/pid/numa_maps.
-
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/