Re: [PATCH 3/4] vmemmap: pull out the vmemmap code into its own file

Christoph Lameter
2007-08-02T19:28:06Z

On Thu, 2 Aug 2007, Christoph Hellwig wrote:

> On Thu, Aug 02, 2007 at 10:25:35AM +0100, Andy Whitcroft wrote:
> > + * Special Kconfig settings:
> > + *
> > + * CONFIG_ARCH_POPULATES_SPARSEMEM_VMEMMAP
> > + *
> > + * The architecture has its own functions to populate the memory
> > + * map and provides a vmemmap_populate function.
> > + *
> > + * CONFIG_ARCH_POPULATES_SPARSEMEM_VMEMMAP_PMD

?? Why was this added? The arch can populate the PMDs on its own already
if CONFIG_ARCH_SPARSEMEM_VMEMMAP is set.

> This is the kinda of mess I mean. Which architecturs set either of these
> and why? This code would be a lot more acceptable if we hadn't three
> different variants of the arch interface.

Initially at least my scheme was the following:

In general the sparsemem code can take care of a vmemmap that is using a
section of the vmalloc space. In that case no arch code is needed to
populate the vmemmap. Typical use is by arches with large pages (like
IA64). This is the default if no other options are set and can simply be
enabled by defining some constants in the arch code to reserve a section
of the vmalloc space.

Then there is the option of using the PMD to map a higher order page. This
can also be done transparently and is used by arches that have this
capability and a small page size. Those arches also require no additional
code to populate their vmemmap. This is true f.e. for i386 and x86_64.
These have to set CONFIG_ARCH_SUPPORTS_PMD_MAPPING

Then there are arches that have the vmemmap in non standard ways. Memory
may not be taken from the vmalloc space, special flags may have to be set
for the page tables (or one may use a different mechanism for mapping).
Those arches have to set CONFIG_ARCH_POPULATES_VIRTUAL_MEMMAP. In that
case the arch must provide its own function to populate the memory map.