[lkml]   [2005]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NUMA mempolicy /proc code in mainline shouldn't have been merged
On Mon, 19 Sep 2005, Andrew Morton wrote:

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

We would be glad to do be more clean on these issues. Its difficult
to see how that can happen when the discussion is blocked on
principle. I have discussed various scenarios in long discussion
threads with Andi. The answer "My code is simple and cannot be changed"
wont get us anywhere.

> 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

I wish I knew how we can improve the communication. I have discussed this
for two months now and tried to respond to every objection and concern
that came up.

> because, as you say, external policy control is going to be a ton harder to
> swallow than /proc/pid/numa_maps.

Could we just do the numa_maps in the right way now and do a code cleanup
for 2.6.14 (node_maps, user interface / system interface separation)? We can
then think longer term about how the memory of a process can be managed.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-20 01:15    [W:0.045 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site