lkml.org 
[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.19pre1aa1
> it's not more complex than the current way, it's just different and it's
> not strict, but it's the best one for allocations that doesn't "prefer"
> memory from a certain node, but OTOH we don't have an API to define
> 'waek' or 'strict' allocation bheaviour so the default would better be
> the 'strict' one like in oldnuma. Infact in the future we may want to
> have also a way to define a "very strict" allocation, that means it
> won't fallback into the other nodes at all, even if there's plenty of
> memory free on them. An API needs to be built with some bitflag
> specifying the "strength" of the numa affinity required. Your layout
> provides the 'weakest' approch, that is perfectly fine for some kind of
> non-numa-aware allocations, just like "very strict" will be necessary
> for the relocation bindings (if we cannot relocate in the right node
> there's no point to relocate in another node, let's ingore complex
> topologies for now :).

Actually, we (IBM) do have a simple API to do this that Matt Dobson
has been working on that's nearing readiness (& publication). I've
been coding up a patch to _alloc_pages today that has both a strict
and non-strict binding in it. It first goes through your "preferred" set of
nodes (defined on a per-process basis), then again looking for any
node that you've not strictly banned from the list - I hope that's
sufficient for what you're discussing? I'll try to publish my part tommorow,
definitely this week - it'll be easy to see how it works in conjunction with
the API, though the rest of the API might be a little longer before arrival ....

Martin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.087 / U:3.196 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site