lkml.org 
[lkml]   [2005]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch 02/38] CKRM e18: Processor Delay Accounting
    Date

    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
    -
    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 23:02    [W:3.325 / U:1.376 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site