lkml.org 
[lkml]   [2005]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-06-23 11:55    [W:0.092 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site