From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andi Kleen <andi@firstfloor.org>
Cc: Yasunori Goto <y-goto@jp.fujitsu.com>,
Gary Hade <garyhade@us.ibm.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Badari Pulavarty <pbadari@us.ibm.com>, Mel Gorman <mel@csn.ul.ie>,
Chris McDermott <lcm@us.ibm.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] [RESEND] x86_64: add memory hotremove config option
Date: Mon, 8 Sep 2008 19:46:30 +1000 [thread overview]
Message-ID: <200809081946.31521.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <20080908093619.GC26079@one.firstfloor.org>
On Monday 08 September 2008 19:36, Andi Kleen wrote:
> > You use non-linear mappings for the kernel, so that kernel data is
> > not tied to a specific physical address. AFAIK, that is the only way
> > to really do it completely (like the fragmentation problem).
>
> Even with that there are lots of issues, like keeping track of
> DMAs or handling executing kernel code.
Right, but the "high level" software solution is to have nonlinear
kernel mappings. Executing kernel code should not be so hard because
it could be handled just like executing user code (ie. the CPU that
is executing will subsequently fault and be blocked until the
relocation is complete).
DMAs aren't trivial at all, but I guess there could be say, a method
to submit and revoke areas of memory for DMA, and the submit would
block if the memory is currently being relocated underneath it (then
it would be able to find the new address).
Anwyay, whatever the case, yeah I'm not trying to say it is trivial
at all. Even without thinking about DMA it would be costly.
> > Of course, I don't think that would be a good idea to do that in the
> > forseeable future.
>
> Agreed.
Same as the "anti-frag" patches. We must not proceed with this kind of
thing on the justification that "in future we'll be able to unplug any
bit of memory". Because it is not just a matter of logical steps to
reach that point, but basically a fundamental rethink of how the kernel
memory mapping should work.
Other realistic justifications are OK, but if someone wants to unplug
everything, then please put effort into *first* making the kernel
mapping nonlinear, and then we can look at the complexity and
performance costs of that fundamental step.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-09-08 9:46 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-05 17:21 Gary Hade
2008-09-05 17:44 ` Ingo Molnar
2008-09-05 18:14 ` Badari Pulavarty
2008-09-05 18:17 ` Ingo Molnar
2008-09-08 21:52 ` [PATCH] Cleanup to make remove_memory() arch neutral Badari Pulavarty
2008-09-09 0:56 ` Andrew Morton
2008-09-09 1:14 ` Randy Dunlap
2008-09-09 1:21 ` Yasunori Goto
2008-09-09 15:12 ` Badari Pulavarty
2008-09-08 21:56 ` [PATCH] x86: add memory hotremove config option Badari Pulavarty
2008-09-05 18:04 ` [PATCH] [RESEND] x86_64: " Andi Kleen
2008-09-05 18:31 ` Badari Pulavarty
2008-09-05 18:54 ` Andi Kleen
2008-09-05 22:34 ` Badari Pulavarty
2008-09-05 19:53 ` Gary Hade
2008-09-05 20:04 ` Andi Kleen
2008-09-05 21:54 ` Gary Hade
2008-09-06 0:01 ` Andi Kleen
2008-09-06 7:06 ` Yasunori Goto
2008-09-06 8:53 ` Andi Kleen
2008-09-08 5:52 ` Nick Piggin
2008-09-08 9:36 ` Andi Kleen
2008-09-08 9:46 ` Nick Piggin [this message]
2008-09-08 10:30 ` Andi Kleen
2008-09-08 11:19 ` Nick Piggin
2008-09-08 11:30 ` Andi Kleen
2008-09-08 13:48 ` Nick Piggin
2008-09-06 14:33 ` Ingo Molnar
2008-09-06 16:00 ` kamezawa.hiroyu
2008-09-06 16:17 ` Ingo Molnar
2008-09-06 16:05 ` kamezawa.hiroyu
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=200809081946.31521.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=garyhade@us.ibm.com \
--cc=lcm@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=pbadari@us.ibm.com \
--cc=x86@kernel.org \
--cc=y-goto@jp.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