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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [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]
  Powered by Linux