lkml.org 
[lkml]   [2012]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 40/40] autonuma: shrink the per-page page_autonuma struct size
    On 06/28/2012 08:56 AM, Andrea Arcangeli wrote:
    > From 32 to 12 bytes, so the AutoNUMA memory footprint is reduced to
    > 0.29% of RAM.

    Still not ideal, however once we get native THP migration working
    it could be practical to switch to a "have a bucket with N
    page_autonuma structures for every N*M pages" approach.

    For example, we could have 4 struct page_autonuma pages, for 32
    memory pages. That would necessitate reintroducing the page pointer
    into struct page_autonuma, but it would reduce memory use by roughly
    a factor 8.

    To get from a struct page to a struct page_autonuma, we would have
    to look at the bucket and check whether one of the page_autonuma
    structs points at us. If none do, we have to claim an available one.
    On migration, we would have to free our page_autonuma struct, which
    would make it available for other pages to use.

    This would complicate the code somewhat, and potentially slow down
    the migration of 4kB pages, but with 2MB pages things could continue
    exactly the way they work today.

    Does this seem reasonably in any way?

    > +++ b/include/linux/autonuma_list.h
    > @@ -0,0 +1,94 @@
    > +#ifndef __AUTONUMA_LIST_H
    > +#define __AUTONUMA_LIST_H
    > +
    > +#include<linux/types.h>
    > +#include<linux/kernel.h>

    > +typedef uint32_t autonuma_list_entry;
    > +#define AUTONUMA_LIST_MAX_PFN_OFFSET (AUTONUMA_LIST_HEAD-3)
    > +#define AUTONUMA_LIST_POISON1 (AUTONUMA_LIST_HEAD-2)
    > +#define AUTONUMA_LIST_POISON2 (AUTONUMA_LIST_HEAD-1)
    > +#define AUTONUMA_LIST_HEAD ((uint32_t)UINT_MAX)
    > +
    > +struct autonuma_list_head {
    > + autonuma_list_entry anl_next_pfn;
    > + autonuma_list_entry anl_prev_pfn;
    > +};

    This stuff needs to be documented with a large comment, explaining
    what is done, what the limitations are, etc...

    Having that documentation in the commit message is not going to help
    somebody who is browsing the source code.

    I also wonder if it would make sense to have this available as a
    generic list type, not autonuma specific but an "item number list"
    include file with corresponding macros.

    It might be useful to have lists with item numbers, instead of
    prev & next pointers, in other places in the kernel.

    Besides, introducing this list type separately could make things
    easier to review.


    --
    All rights reversed


    \
     
     \ /
      Last update: 2012-07-02 10:01    [W:4.074 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site