[PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework

[Peter Zijlstra]

On Thu, 2010-08-26 at 03:28 +0200, Michał Nazarewicz wrote:
> On Fri, 20 Aug 2010 15:15:10 +0200, Peter Zijlstra <peterz at infradead.org> wrote:
> > So the idea is to grab a large chunk of memory at boot time and then
> > later allow some device to use it?
> >
> > I'd much rather we'd improve the regular page allocator to be smarter
> > about this. We recently added a lot of smarts to it like memory
> > compaction, which allows large gobs of contiguous memory to be freed for
> > things like huge pages.
> >
> > If you want guarantees you can free stuff, why not add constraints to
> > the page allocation type and only allow MIGRATE_MOVABLE pages inside a
> > certain region, those pages are easily freed/moved aside to satisfy
> > large contiguous allocations.
> 
> I'm aware that grabbing a large chunk at boot time is a bit of waste of
> space and because of it I'm hoping to came up with a way of reusing the
> space when it's not used by CMA-aware devices.  My current idea was to
> use it for easily discardable data (page cache?). 

Right, so to me that looks like going at the problem backwards. That
will complicate the page-cache instead of your bad hardware drivers
(really, hardware should use IOMMUs already).

So why not work on the page allocator to improve its contiguous
allocation behaviour. If you look at the thing you'll find pageblocks
and migration types. If you change it so that you pin the migration type
of one or a number of contiguous pageblocks to say MIGRATE_MOVABLE, so
that they cannot be used for anything but movable pages you're pretty
much there.