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

From: Shailabh Nagar
Date: Thu Jun 23 2005 - 12:55:58 EST

Ingo Molnar wrote:
* Ingo Molnar <mingo@xxxxxxx> wrote:

* Gerrit Huizenga <gh@xxxxxxxxxx> wrote:

+int task_running_sys(struct task_struct *p)
+ return task_is_running(p);

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).


+#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 ?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at