Re: Fwd: [PATCH] kmemcheck: SMP support

[Pekka Paalanen <pq@iki.fi>]

On Fri, 23 May 2008 16:19:43 +0200
"Vegard Nossum" <vegard.nossum@gmail.com> wrote:

> Oops, forgot to put you on Cc. I thought you might find this
> interesting as well... :-)

Yes, thanks. My opinion is that mmiotrace can live well enough with
runtime-disabling extra cpus when tracing starts. Multi-cpu effects to
hardware access are not really in the focus but seeing the access in
the first place. I'd rather wait to see if the per-cpu page table
feature starts to evolve.

I quickly read through your code and tried to come up with race
scenarios, but failed. Ok, one question which might be far fetched:
is there a window for things to go wrong, when one cpu has faulted
and is submitting the NMI, but another cpu is managing cpus' online
state at the time? Is there a place in the cpu state management
that might fault at a point where cpu maps are inconsistent?
I doubt, but I don't know. And of course this could be a problem
only when something is bringing cpus on- or offline.

Btw. isn't reserving a cpumask_t variable from the stack discouraged
because it might have to deal with thousands of cpus and consume a
lot of memory?


Thanks.

> ---------- Forwarded message ----------
> From: Vegard Nossum <vegard.nossum@gmail.com>
> Date: Fri, May 23, 2008 at 4:17 PM
> Subject: [PATCH] kmemcheck: SMP support
> To: Ingo Molnar <mingo@elte.hu>, Pekka Enberg <penberg@cs.helsinki.fi>
> Cc: linux-kernel@vger.kernel.org
> 
> 
> Hi,
> 
> This works on real hw, but not on qemu. It seems to get stuck waiting for one
> of the atomic values to change. Don't know why yet, it might just be yet
> another bug in qemu... (we've hit at least two of them so far. And they were
> real bugs too.)
> 
> But do you think this approach is feasible? It will kill interactivity,
> that's for sure, though only when kmemcheck is run-time enabled and number
> of CPUs > 1 (the more the worse).
> 

-- 
Pekka Paalanen
http://www.iki.fi/pq/