RE: [Lhms-devel] RE: memory hotremove prototype, take 3

From: Perez-Gonzalez, Inaky
Date: Thu Dec 04 2003 - 00:01:01 EST

> -----Original Message-----
> From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Yasunori Goto
> Sent: Wednesday, December 03, 2003 1:23 PM
> To: Perez-Gonzalez, Inaky
> Cc: Pavel Machek; linux-kernel@xxxxxxxxxxxxxxx; Luck, Tony; IWAMOTO Toshihiro; Hirokazu Takahashi; Linux Hotplug Memory Support
> Subject: Re: [Lhms-devel] RE: memory hotremove prototype, take 3
> > > IMHO, To hot-remove memory, memory attribute should be divided
> > > into Hotpluggable and no-Hotpluggable, and each attribute memory
> > > should be allocated each unit(ex. node).
> >
> > Why? I still don't get that -- we should be able to use the virtual
> > addressing mechanism of any CPU to swap under the rug any virtual
> > address without needing to do anything more than allocate a page frame
> > for the new physical location
> My understanding is that the kernel and device drivers sometimes
> assume physical memory address is not changed.
> For example, IA32 kernel often uses __PAGE_OFFSET.
> I suppose that there are many case which the kernel and device drivers
> assume physical address is not changed like this.
> Even if we use Mr. Iwamoto's method use, some memories will remain.

Grrrr ... my concern is that Murphy's Law says that we'll need to hotplug
the memory that we cannot in most of the cases (pray not). I guess I will
need to research some more to think how to do it.

I still think we could use the CPU's virtualization mechanism--of course,
and as you and Tony Luck mention, we'd had to track down and modify the
parts that assume physical memory et al. That they use large pages or
not doesn't seem to be such a big problem (other than allocating a bigger
chunk for transfer) and that performance wise, it'd take longer to
do _that_ part, but still I prefer it to taking the machine down.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at