lkml.org 
[lkml]   [2004]   [Apr]   [8]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 09 Apr 2004 11:37:45 +0900
FromIWAMOTO Toshihiro <>
SubjectRe: [patch 0/3] memory hotplug prototype
At Thu, 08 Apr 2004 09:56:35 -0700,
Martin J. Bligh <mbligh@aracnet.com> wrote:
> 
> > At Wed, 07 Apr 2004 11:12:55 -0700,
> > Martin J. Bligh <mbligh@aracnet.com> wrote:
> >> 
> >> > This is an updated version of memory hotplug prototype patch, which I
> >> > have posted here several times.
> >> 
> >> I really, really suggest you take a look at Dave McCracken's work, which
> >> he posted as "Basic nonlinear for x86" recently. It's going to be much
> >> much easier to use this abstraction than creating 1000s of zones ...
> > 
> > Well, I think his patch is orthogonal to mine.  My ultimate target
> > is IA64 and it will only support node-sized memory hotplugging.
> 
> Are you saying you're only creating a patch for ia64 only, rather than
> an arch-independant one?

I'm not trying to make my patches IA64 specific, and my patch is quite
machine independent.  However, some of them, such as placing mem_map at
boot time or hotplug events, are machine dependent by nature.

I'm afraid that the memsection thing is overkill for systems whose
hotpluggable memory unit is large.  I understand there's need for
memsection, but I think that should be optional.

BTW, I think memory hotplugging on 32 bit archs are difficult because
of their narrow address space.  For example:
	1. A system boots with 1GB * 4 blocks of RAM.
	2. The second RAM block is removed.
	3. A 2GB block is inserted in the second slot.
Where does these RAM block appear in physical space, and where should
their mem_map be placed?

--
IWAMOTO Toshihiro


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

\
 
 \ /
  Last update: 2005-03-22 13:02    [from the cache]
©2003-2008