On Mon, Jul 02, 2012 at 02:37:10AM -0400, Rik van Riel wrote:
> > +fail:
> > + printk(KERN_CRIT "allocation of page_autonuma failed.\n");
> > + printk(KERN_CRIT "please try the 'noautonuma' boot option\n");
> > + panic("Out of memory");
> > +}
>
> The system can run just fine without autonuma.
>
> Would it make sense to simply disable autonuma at this point,
> but to try continue running?
BTW, the same would apply to mm/page_cgroup.c, but I think the idea
here is that something serious went wrong. Workaround with noautonuma
boot option is enough.
>
> > @@ -700,8 +780,14 @@ static void free_section_usemap(struct page *memmap, unsigned long *usemap)
> > */
> > if (PageSlab(usemap_page)) {
> > kfree(usemap);
> > - if (memmap)
> > + if (memmap) {
> > __kfree_section_memmap(memmap, PAGES_PER_SECTION);
> > + if (!autonuma_impossible())
> > + __kfree_section_page_autonuma(page_autonuma,
> > + PAGES_PER_SECTION);
> > + else
> > + BUG_ON(page_autonuma);
>
> VM_BUG_ON ?
>
> > + if (!autonuma_impossible()) {
> > + struct page *page_autonuma_page;
> > + page_autonuma_page = virt_to_page(page_autonuma);
> > + free_map_bootmem(page_autonuma_page, nr_pages);
> > + } else
> > + BUG_ON(page_autonuma);
>
> ditto
>
> > pgdat_resize_unlock(pgdat,&flags);
> > if (ret<= 0) {
> > + if (!autonuma_impossible())
> > + __kfree_section_page_autonuma(page_autonuma, nr_pages);
> > + else
> > + BUG_ON(page_autonuma);
>
> VM_BUG_ON ?
These only run at the very boot stage, so performance is irrelevant
and it's safer to keep them on.
The rest was corrected.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>