[lkml]   [2012]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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_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:0.555 / U:1.156 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site