Messages in this thread | | | Date | Thu, 23 Jun 2005 11:37:32 +0200 | From | Ingo Molnar <> | Subject | Re: [patch 02/38] CKRM e18: Processor Delay Accounting |
| |
* Ingo Molnar <mingo@elte.hu> wrote:
> > * Gerrit Huizenga <gh@us.ibm.com> wrote: > > > +#ifdef CONFIG_DELAY_ACCT > > +int task_running_sys(struct task_struct *p) > > +{ > > + return task_is_running(p); > > +} > > +EXPORT_SYMBOL_GPL(task_running_sys); > > +#endif > > why is this function defined, and why is it exported?
this:
+#define task_is_running(p) (this_rq() == task_rq(p))
is totally bogus. What you are checking is not whether 'the task is running', but it is a complex way of doing p->thread_info->cpu == smp_processor_id(). This, combined with:
+ if (pdata == NULL) + /* some wierdo race condition .. simply ignore */ + continue; + if (thread->state == TASK_RUNNING) { + if (task_running_sys(thread)) { + atomic_inc((atomic_t *) & + (PSAMPLE(pdata)->cpu_running)); + run++; + } else { + atomic_inc((atomic_t *) & + (PSAMPLE(pdata)->cpu_waiting)); + wait++; + } + }
yields completely incorrect code, and bogus data. If your goal is to sample executing-on-cpu vs. on-runqueue-waiting-to-run states then you should use the already existing task_curr(p) call.
Ingo - 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/
| |