Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

[Kamezawa Hiroyuki]

Ingo Molnar wrote:
> so it's all about expectations: _could_ you reasonably remove a piece of 
> RAM? Customer will say: "I have stopped all nonessential services, and 
> free RAM is at 90%, still I cannot remove that piece of faulty RAM, fix 
> the kernel!". No reasonable customer will say: "True, I have all RAM 
> used up in mlock()ed sections, but i want to remove some RAM 
> nevertheless".
Hi, I'm one of men in -lhms

In my understanding...
- Memory Hotremove on IBM's LPAR? approach is
  [remove some amount of memory from somewhere.]
  For this approach, Mel's patch will work well.
  But this will not guaranntee a user can remove specified range of
  memory at any time because how memory range is used is not defined by an admin
  but by the kernel automatically. But to extract some amount of memory,
  Mel's patch is very important and they need this.

My own target is NUMA node hotplug, what NUMA node hotplug want is
- [remove the range of memory] For this approach, admin should define
  *core* node and removable node. Memory on removable node is removable.
  Dividing area into removable and not-removable is needed, because
  we cannot allocate any kernel's object on removable area.
  Removable area should be 100% removable. Customer can know the limitation before using.

What I'm considering now is this:
- removable area is hot-added area
- not-removable area is memory which is visible to kernel at boot time.
(I'd like to achieve this by the limitation : hot-added node goes into only ZONE_HIGHMEM)
A customer can hot add their extra memory after boot. This is very easy to understand.
Peformance problem is trade-off.(I'm afraid of this ;)

If a cutomer wants to guarantee some memory areas should be hot-removable,
he will hot-add them.
I don't think adding memory for the kernel by hot-add is wanted by a customer.

-- Kame

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