[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, Andi Kleen wrote:

> On Mon, Sep 19, 2005 at 10:11:20AM -0700, Christoph Lameter wrote:
> > However, one still does not know which memory section (vma) is allocated
> > on which nodes. And this may be important since critical data may need to
> Maybe. Well sure of things could be maybe important. Or maybe not.
> Doesn't seem like a particularly strong case to add a lot of ugly
> code though.

We gradually need to fix the deficiencies of the policy layer. Calling
fixes "ugly code" and refusing to discuss solutions does not help anyone.

> > External memory policy management is a necessary feature for system
> > administration, batch process scheduling as well as for testing and
> > debugging a system.
> I'm not convinced of this at all. Most of these things proposed so far
> can be done much simpler with 90% of the functionality (e.g. just swapoff
> per process for migration) , and I haven't seen a clear rationale except
> for lots of maybes that the missing 10% are worth all the complexity
> you seem to plan to add.

Have you ever had the challenge to work with large HPC applications on a
large NUMA system? Which things? Many HPC apps do not use swap space
at all and we likely wont be using swap for page migration (see Marcelo's
work on a migration cache). All I have heard is you imagining complex
solutions ("performance counters" etc) to things that would be simple if
the policy layer would be up to the task.
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-19 23:34    [W:0.041 / U:0.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site