Re: [PATCH] memory hotadd fixes [4/5] avoid check in acpi

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Thu, 03 Aug 2006 18:54:32 -0700
keith mannthey <kmannth@us.ibm.com> wrote:

> > Hmm..Okay. I'll try some check patch today. please review it.
> > Maybe moving ioresouce collision check in early stage of add_memory() is good ?
>   Yea.  I am working a a full patch set for but my sparsemem and reserve
> add-based paths.  It creates a valid_memory_add_range call at the start
> of add_memory. I should be posting the set in the next few hours.
> 
Ah..ok. but I wrote my own patch...and testing it now..

> > Note:
> > I remove pfn_valid() here because pfn_valid() just says section exists or
> > not. When adding seveal small memory chunks in one section, Only the  first
> > small chunk can be added. 
> Hmm... I thought memory add areas needed to be section aligned for the arch?
> 
There are requests for memory-hot-add should allow to hot-add not-aligned memory.
Then, I wrote ioresouce collision check patch (before..but had bug..)
With ioresouce collistion check, alignments are not required at *add*.
(onlining is just for  *offlined section*, now)

>   What protecting is there for calling add_memory on an already present
> memory range?  
> 
For example, considering ia64, which has 1Gbytes section...
hot add following region.
==
(A) 0xc0000000 - 0xd7ffffff  (section 3)
(B) 0xe0000000 - 0xffffffff  (section 3)
==
(A) and (B) will go to the same section, but there is a memory hole between
(A) and (B). Considering memory (B) appears after (A) in DSDT.

After add_memory() against (A) is called, section 3 is ready.
Then, pfn_valid(0xe0000000) and pfn_valid(0xffffffff) returns true because
they are in section 3.
So, checking pfn_valid() for (B) will returns true and memory (B) cannot be
added. ioresouce collision check will help this situation.

The memory hole are not onlined because there are no ioresouce for it.

-Kame


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/