ZONE_NORMAL is by definition limited by the direct mapping size, so if
you don't have enough virtual space you cannot enlarge the zone_normal
anyways. If need more virtual space you can only do things like
CONFIG_2G.
> need, plus the holes? Config_nonlinear handles that, config_discontig
> doesn't.
>
> > > No, you don't need to call changing that mapping "CONFIG_NONLINEAR",
> > > but that's basically what the bulk of Dan's patch does, so I think we should
> > > steal it with impunity ;-)
> >
> > The difference is that if you use discontigmem you don't clobber the
> > common code in any way,
>
> First that's wrong. Look at _alloc_pages and tell me that config_discontig
> doesn't impact the common code (in fact, it adds two extra subroutine
> calls, including two loops, to every alloc_pages call).
there are no two subroutines, check -aa. And the whole point is that we
need a topology description of the machine for numa, nonlinear or not,
what you're talking about is the whole numa concept in 2.4, it is all
but superflous, while nonlinear implications in common code are
superflous just to provide ZONE_NORMAL in more than one node in numa-q.
>
> Secondly, config_nonlinear does not clobber the common code. If it does,
> please show me where.
>
> When config_nonlinear is not enabled, suitable stubs are provided to make it
> transparent.
it's the stubs that are visible to the common code and that are
superflous.
> > Actually the same mmu technique can be used to coalesce in virtual
> > memory the discontigous chunks of iSeries, then you left the lookup in
> > the tree to resolve from mem_map to the right virtual address and from
> > the right virtual address back to mem_map. (and you left DISCONTIGMEM
> > disabled) I think it should be possible.
>
> So you're proposing a new patch? Have you chosen a name for it? How
> about 'config_nonlinear'? ;-)
They're called CONFIG_MULTIQUAD and CONFIG_MSCHUNKS.
Andrea
-
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/