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

[Andrew Morton]

Christoph Lameter <clameter@xxxxxxxxxxxx> wrote:
>
> On Sat, 10 Sep 2005, Andrew Morton wrote:
> 
> > Andi Kleen <ak@xxxxxxx> wrote:
> > >
> > >  Just noticed the ugly SGI /proc/*/numa_maps code got merged.
> 
> Well its ugly because you said that the fixes to make it less ugly were 
> "useless". I can still submit those fixes that make numa_maps a part of 
> smaps and that cleanup the way policies are displayed.

It would be useful to see these.

> > >  - it presents lots of kernel internal information and mempolicy
> > >  internals (like how many people have a page mapped) etc.
> > >  to userland that shouldn't be exposed to this.
> 
> Very important information.
>

Important to whom?  Kernel developers or userspace developers?  If the
latter, what use do they actually make of it?  Shouldn't it be documented?

> > >  - there is no demonstrated application that needs it
> > >  (there was a theoretical usecase where it might be needed,
> > >  but there were better solutions proposed for this) 
> 
> Could you be more specific? The application is to figure out how memory is 
> placed. Just to cat /proc/<pid>/numa_maps. Seems to be a favorite with 
> some people.

If it's useful to application developers then fine.  It it's only useful to
kernel developers then the argument is weakened.  However there's still
quite a lot of development going on in this area, so there's still some
argument for having the monitoring ability in the mainline tree.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/