Messages in this thread | | | Date | Thu, 23 Jun 2005 13:55:57 -0400 | From | Shailabh Nagar <> | Subject | Re: [ckrm-tech] Re: [patch 02/38] CKRM e18: Processor Delay Accounting |
| |
Ingo Molnar wrote: > * 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?
The wrapping of the macro and export of the function was to allow its use by a module (crbce).
> > 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.
Thanks. task_curr is what we needed. Would exporting task_curr be ok or should we continue to wrap in a separate function ?
--Shailabh
- 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/
| |