Christoph Lameter <[email protected]> wrote:
>
> On Sat, 10 Sep 2005, Andrew Morton wrote:
>
> > Andi Kleen <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |