Re: [PATCH 36 of 41] remove PG_buddy

[Andrea Arcangeli <aarcange@redhat.com>]

On Mon, Mar 29, 2010 at 03:30:37PM -0700, Dave Hansen wrote:
> Don't forget that include/linux/memory_hotplug.h uses mapcount a bit for
> marking bootmem.  So, just for clarity, we'd probably want to use -5 or
> something.
>         
>         /*
>          * Types for free bootmem.
>          * The normal smallest mapcount is -1. Here is smaller value than it.
>          */
>         #define SECTION_INFO            (-1 - 1)
>         #define MIX_SECTION_INFO        (-1 - 2)
>         #define NODE_INFO               (-1 - 3)

So this is the memory holding the struct page and pgdat info that is
released when the memory is hot-removed? Why isn't
register_page_bootmem_info_node up to get_page_bootmem all let it go
in the __init section together with their only caller? 

what is the reader of that type field? is it only put_page_bootmem?
Just for this BUG_ON?

     BUG_ON(type >= -1);

and what is this about?

    if (atomic_dec_return(&page->_count) == 1) {

How can this every return 0?

Yes I can use -5 no problem, that's no big deal but I don't get how
this _mapcount type info is used and why. Well the BUG_ON above is
obvious but I wonder if it's just for a BUG_ON. If it's just for a
BUG_ON can we just move the layering violation to page->lru.next and
leave mapcount -2 for PageBuddy?

> Looks like SLUB also uses _mapcount for some fun purposes:
>         
>         struct page {
>                 unsigned long flags;            /* Atomic flags, some possibly
>                                                  * updated asynchronously */
>                 atomic_t _count;                /* Usage count, see below. */
>                 union {
>                         atomic_t _mapcount;     /* Count of ptes mapped in mms,
>                                                  * to show when page is mapped
>                                                  * & limit reverse map searches.
>                                                  */
>                         struct {                /* SLUB */
>                                 u16 inuse;
>                                 u16 objects;
>                         };
>                 };
> 
> I guess those don't *really* become a problem in practice until we get a
> really large page size that can hold >=64k objects.  But, at that point,
> we're overflowing the types anyway (or really close to it).  

Maybe we should add a BUG_ON in slub in case anybody runs this on
PAGE_SIZE == 2M (to avoid silent corruption).

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>