Re: [patch 02/38] CKRM e18: Processor Delay Accounting

Gerrit Huizenga
2005-06-23T20:57:12Z

On Thu, 23 Jun 2005 11:37:32 +0200, 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?

This was exported so it could be used in the classification engine
which is a loadable module which determines how and when tasks join
classes. There are two classification engines - a basic one (RBCE)
and a more advanced one (CRBCE). The latter allows a user to set some
basic rules on how newly created tasks will join a class.

> 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

I'll clean this up later this afternoon and regen a patch.

thanks!

gerrit