Re: [Lhns-devel] Merging Nonlinear and Numa style memory hotplug

From: Dave Hansen
Date: Wed Jun 23 2004 - 17:45:51 EST


First of all, thank you for merging nonlinear on top of your current
work. It looks very promising.

On Tue, 2004-06-22 at 12:00, Yasunori Goto wrote:
> - Some of strucure's member are added to mem_section[] to
> unify between nonlinear and node style hotplug.

This quadruples the size of the mem_section[] array, and makes each
mem_section entry take up a whole cache line. Are you sure all of these
structure members are needed? Can they be allocated elsewhere, instead
of directly inside the translation tables, or otherwise derived? Also,
why does the booked/free_count have to be kept here? Can't that be
determined by simply looping through and looking at all the pages'
flags?

Also, can you provide a patch which is just your modifications to Dave's
original nonlinear patch?

Instead of remove_from_freelist(unsigned int section), I'd hope that we
could support a much more generic interface in the page allocator:
allocate by physical address. remove_from_freelist() has some intimate
knowledge of the buddy allocator that I think is a bit complex.

That also brings up a more important issue. I see nonlinear as a
back-end for only the page_to_pfn() and pfn_to_page(), and that's all.
There are no real exposures of the nonlinear section size or the
structures to any other part of the kernel because they're all wrapped
up in those functions. It may be possible to keep the entire kernel
oblivious of nonlinear, but I think it's a worthy goal. That's why I'd
like to see the buddy allocator modifications be limited to
currently-existing concepts like physical addresses.

Brad, do you have anything that you can post to demonstrate your
approach for doing allocation by address?

-- Dave

-
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/