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

Christoph Lameter
2005-09-10T16:29:50Z

On Sat, 10 Sep 2005, Andrew Morton wrote:

> Andi Kleen <ak@suse.de> 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.

> Been in -mm for over two months.
>
> > I argued several times against it

Nope you argued against changing memory policies via proc. The numa_maps
patch is displaying on which node a vma uses memory.

> > and I very deliberately didn't include
> > a similar facility when I wrote the NUMA policy code because it's a bad
> > idea.

Thats the idea of changing memory policies right? NBot displaying memory
usages across nodes?

> > - 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. Somewhat similar information is already
available via smaps.

> > - the format is very complicated and the chance of bug free
> > userland parsers of this is near zero.

What is complicated about the format? And the basic use is to see where
memory for it was placed. I have code here that parses the format.

> > - 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.

> > Can the patch please be removed?
>
> OK by me. I queued a revert patch.

No idea why that would be necessary.