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

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