[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080908113025.GF26079@one.firstfloor.org>
Date: Mon, 8 Sep 2008 13:30:25 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: Andi Kleen <andi@...stfloor.org>,
Yasunori Goto <y-goto@...fujitsu.com>,
Gary Hade <garyhade@...ibm.com>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Badari Pulavarty <pbadari@...ibm.com>,
Mel Gorman <mel@....ul.ie>, Chris McDermott <lcm@...ibm.com>,
linux-kernel@...r.kernel.org, x86@...nel.org,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] [RESEND] x86_64: add memory hotremove config option
> Sorry, by "block", I really mean spin I guess. I mean that the CPU will
> be forced to stop executing due to the page fault during this sequence:
It's hard for NMIs at least. They cannot execute faults.
In the end you would need to define a core kernel which
cannot be remapped and the rest which can and you end up
with even more micro kernel like mess.
> ptep_clear_flush(ptep) <--- from here
> set_pte(ptep, newpte) <--- until here
>
> for prot RW, the window also would include the memcpy, however if that
> adds too much latency for execute/reads, then it can be mapped RO first,
> then memcpy, then flushed and switched.
>
>
> > Then that would be essentially a hypervisor or micro kernel approach.
>
> What would be? Blocking in interrupts? Or non-linear kernel mapping in
Well in general someone remapping all the memory beyond you.
That's essentially a hypervisor in my book.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists