Re: [PATCH 2/11] oprofile: arch-independent code for stack tracesampling
From: Greg Banks
Date: Tue Nov 09 2004 - 06:43:44 EST
On Tue, 2004-11-09 at 22:05, Andrew Morton wrote:
> Greg Banks <gnb@xxxxxxxxxxxxxxxxx> wrote:
> > + struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[smp_processor_id()];
> oprofile is currently doing suspicious things with smp_processor_id() in
> premptible reasons. Is this patch compounding things?
It's not changing the contexts where smp_processor_id() is called,
just pushing it down one level from a bunch of interrupt handlers
to the 2 oprofile sampling functions they call. If it was busted
before it's no more nor less busted now.
I presume the perceived problem is that with CONFIG_PREEMPT=y the
thread can be pre-empted onto another CPU? If it makes everyone
happier I can sprinkle a few preempt_disable()s around, but I'd
prefer to do it in a subsequent patch rather than respin this.
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/