Messages in this thread | | | Subject | Re: [PATCH 2/11] oprofile: arch-independent code for stack trace sampling | From | Greg Banks <> | Date | Tue, 09 Nov 2004 22:35:48 +1100 |
| |
On Tue, 2004-11-09 at 22:05, Andrew Morton wrote: > Greg Banks <gnb@melbourne.sgi.com> 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. -- 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |