From: "Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>
To: "Yasunori Goto" <ygoto@fsw.fujitsu.com>
Cc: "Pavel Machek" <pavel@suse.cz>, <linux-kernel@vger.kernel.org>,
"Luck, Tony" <tony.luck@intel.com>,
"IWAMOTO Toshihiro" <iwamoto@valinux.co.jp>,
"Hirokazu Takahashi" <taka@valinux.co.jp>,
"Linux Hotplug Memory Support" <lhms-devel@lists.sourceforge.net>
Subject: RE: [Lhms-devel] RE: memory hotremove prototype, take 3
Date: Wed, 3 Dec 2003 20:59:04 -0800 [thread overview]
Message-ID: <A20D5638D741DD4DBAAB80A95012C0AE0125DD50@orsmsx409.jf.intel.com> (raw)
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Yasunori Goto
> Sent: Wednesday, December 03, 2003 1:23 PM
> To: Perez-Gonzalez, Inaky
> Cc: Pavel Machek; linux-kernel@vger.kernel.org; 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)
next reply other threads:[~2003-12-04 4:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-04 4:59 Perez-Gonzalez, Inaky [this message]
2003-12-04 9:54 ` [Lhms-devel] RE: memory hotremove prototype, take 3 Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2003-12-04 20:06 Luck, Tony
2003-12-04 16:12 Perez-Gonzalez, Inaky
2003-12-04 10:37 Perez-Gonzalez, Inaky
2003-12-04 11:01 ` Pavel Machek
2003-12-03 5:19 Perez-Gonzalez, Inaky
2003-12-03 21:23 ` [Lhms-devel] " Yasunori Goto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A20D5638D741DD4DBAAB80A95012C0AE0125DD50@orsmsx409.jf.intel.com \
--to=inaky.perez-gonzalez@intel.com \
--cc=iwamoto@valinux.co.jp \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=taka@valinux.co.jp \
--cc=tony.luck@intel.com \
--cc=ygoto@fsw.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).