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

[Michal Nazarewicz]

On Fri, 01 Apr 2011 00:26:51 +0200, Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>  
wrote:

> On Fri, 2011-04-01 at 00:18 +0200, Michal Nazarewicz wrote:
> > On Thu, 31 Mar 2011 23:14:38 +0200, Dave Hansen wrote:
> > > We BUG_ON() in bootmem.  Basically if we try to allocate an early-boot
> > > structure and fail, we're screwed.  We can't keep running without an
> > > inode hash, or a mem_map[].
> > >
> > > This looks like it's going to at least get partially used in drivers,  
> > at
> > > least from the examples.  Are these kinds of things that, if the  
> > driver
> > > fails to load, that the system is useless and hosed?  Or, is it
> > > something where we might limp along to figure out what went wrong  
> > before
> > > we reboot?
> >
> > 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.

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.

--
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michal "mina86" Nazarewicz    (o o)
ooo +-----<email/xmpp: mnazarewicz@xxxxxxxxxx>-----ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/