[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18745.2198.389098.296393@cargo.ozlabs.ibm.com>
Date: Fri, 5 Dec 2008 21:55:18 +1100
From: Paul Mackerras <paulus@...ba.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Stephane Eranian <eranian@...glemail.com>,
Eric Dumazet <dada1@...mosbay.com>,
Robert Richter <robert.richter@....com>,
Arjan van de Veen <arjan@...radead.org>,
Peter Anvin <hpa@...or.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Steven Rostedt <rostedt@...dmis.org>,
David Miller <davem@...emloft.net>
Subject: Re: [patch 1/3] performance counters: core code
Thomas Gleixner writes:
> +static void
> +perf_install_in_context(struct perf_counter_context *ctx,
> + struct perf_counter *counter,
> + int cpu)
> +{
> + struct task_struct *task = ctx->task;
> +
[...]
> + if (task) {
> + task_oncpu_function_call(task, __perf_install_in_context,
> + counter);
> + } else {
> + smp_call_function_single(cpu, __perf_install_in_context,
> + counter, 1);
> + }
What happens if we send an IPI to the cpu where the task is running,
but by the time the IPI arrives, the task has been migrated to another
cpu and is now running there? Do you chase after it and send another
IPI to its new cpu, or is there some reason why it can't migrate?
If it's the former, where is that code? I haven't seen it so far (at
least, task_oncpu_function_call doesn't seem to do it).
Paul.
--
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