Re: [PATCH 3/7] Generic Virtual Memmap support for SPARSEMEM

Christoph Lameter
2007-07-13T23:17:32Z

On Sat, 14 Jul 2007, KAMEZAWA Hiroyuki wrote:

> Just because this patch takes care of boot path. Maybe small problem.

Ahh. I just looked at it. Yes we did not modify the hotplug path. It needs
to call the new vmemmap alloc functions.

> Basically, I welcome this patch. I like this.

Yes you proposed the initial version of this last year. Thanks.

> If we can remove DISCONTIG+VMEMMAP after this is merged, we can say good-bye
> to terrible CONFIG_HOLES_IN_ZONE :)

Right. Horrible stuff. Lots of useless cachelines that have to be
references in critical paths.

> Note
> >From memory hotplug development/enhancement view, I have following thinking now.
>
> 1. memmap's section is *not* aligned to "big page size". We have to take care
> of this at adding support for memory_hotplug/unplug.

You can call the functions for virtual memmap allocation directly. They
are already generic and will call the page allocator instead of the
bootmem allocator if the system is already. They will give you the
properly aligned memory. Perhaps you can just change a few lines
in sparse_add_one_section to call the vmemmap functions instead?

> 2. With an appropriate patch, we can allocate new section's memmap from
> itself. This will reduce possibility of memory hotplug failure becasue of
> large size kmalloc/vmalloc. And it guarantees locality of memmap.
> But maybe need some amount of work for implementing this in clean way.
> This will depend on vmemmap.

That is a good idea. Maybe do the simple approach first and then the other
one?

>
> 3. removin memmap code for memory unplug will be necessary. But there is no code
> for removing memmap in usual SPARSEMEM. So this is not real problem of vmemmap
> now.

Right. It would have to be added later anyways.