Re: 2.4.19pre1aa1

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Mar 04, 2002 at 10:26:30PM -0300, Rik van Riel wrote:
> On Tue, 5 Mar 2002, Andrea Arcangeli wrote:
> > On Mon, Mar 04, 2002 at 09:01:31PM -0300, Rik van Riel wrote:
> > > This could be expressed as:
> > >
> > > "node A"  HIGHMEM A -> HIGHMEM B -> NORMAL -> DMA
> > > "node B"  HIGHMEM B -> HIGHMEM A -> NORMAL -> DMA
> >
> > Highmem? Let's assume you speak about "normal" and "dma" only of course.
> >
> > And that's not always the right zonelist layout. If an allocation asks for
> > ram from a certain node, like during the ram bindings, we should use the
> > current layout of the numa zonelist. If node A is the preferred, than we
> > should allocate from node A first,
> 
> You're forgetting about the fact that this NUMA box only

the example you made doesn't have highmem at all.

> has 1 ZONE_NORMAL and 1 ZONE_DMA while it has multiple
> HIGHMEM zones...

it has multiple zone normal and only one zone dma. I'm not forgetting
that.

> This makes the fallback pattern somewhat more complex.

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

Andrea