Re: Page allocator: Single Zone optimizations

Christoph Lameter
2006-11-01T23:29:11Z

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.

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.