Re: Page allocator: Single Zone optimizations

Andrew Morton
2006-11-02T00:22:21Z

On Wed, 1 Nov 2006 15:29:11 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> On Wed, 1 Nov 2006, Mel Gorman wrote:
>
> > > I still think that we need to generalize the approach to be
> > > able to cover as much memory as possible. Remapping can solve some of the
> > > issues, for others we could add additional ways to make things movable.
> > > F.e. one could make page table pages movable by adding a back pointer to
> > > the mm, reclaimable slab pages by adding a move function, driver
> > > allocations could have a backpointer to the driver that would be able to
> > > move its memory.
> >
> > I got the impression that we wouldn't be allowed to introduce such a mechanism
> > because driver writers would get it wrong. It was why proper defragmentation
> > was never really implemented.
>
> I think that choice is better than fiddling with the VM by adding
> additional zones which will introduce lots of other problems.

What lots of other problems? 64x64MB zones works good.

> The ability to move memory in general is beneficial for many purposes.
> Defragmentation is certainly one of them. If all memory would be movable
> then you would not need the separate list in the zone either.
>
> Maybe we can have special mempools for unreclaimable
> allocations for starters and with that have the rest of memory be
> movable? Then we can gradually reduce the need for unreclaimable memory.
> Maybe we can keep unmovable memory completely out of the page allocator?
>
> With that approach we would not break the NUMA layer because we can keep
> the one zone per node approach for memory policies. The special
> unreclaimable memory would not obey memory policies (which makes sense
> since device driverws do not want user space policies applied to their
> allocations anyways. Device drivers need memory near the device).
>
> > > Hmm.... Maybe generally a way to provide a
> > > function to move data in the page struct for kernel allocations?
> > >
> > As devices are able to get physical addresses which then get pinned for IO, it
> > gets messy.
>
> Right. So the device needs to disengage and then move its structures.

I don't think we have a snowball's chance of making all kernel memory
relocatable. Or even a useful amount of it.