[PATCH 04/12] mm: alloc_contig_freed_pages() added

On Fri, 2011-04-01 at 00:51 +0200, Michal Nazarewicz wrote:

On Fri, 01 Apr 2011 00:26:51 +0200, Dave Hansen [off-list ref]  
wrote:

quoted

quoted

Bug in the above place does not mean that we could not allocate  
memory.  It means caller is broken.

Could you explain that a bit?

Is this a case where a device is mapped to a very *specific* range of
physical memory and no where else?  What are the reasons for not marking
it off limits at boot?  I also saw some bits of isolation and migration
in those patches.  Can't the migration fail?

The function is called from alloc_contig_range() (see patch 05/12) which
makes sure that the PFN is valid.  Situation where there is not enough
space is caught earlier in alloc_contig_range().

alloc_contig_freed_pages() must be given a valid PFN range such that all
the pages in that range are free (as in are within the region tracked by
page allocator) and of MIGRATETYPE_ISOLATE so that page allocator won't
touch them.

OK, so it really is a low-level function only.  How about a comment that
explicitly says this?  "Only called from $FOO with the area already
isolated."  It probably also deserves an __ prefix.

That's why invalid PFN is a bug in the caller and not an exception that
has to be handled.

Also, the function is not called during boot time.  It is called while
system is already running.

What kind of success have you had running this in practice?  I'd be
worried that some silly task or a sticky dentry would end up in the
range that you want to allocate in.  


-- Dave