lkml.org 
[lkml]   [2012]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Question] sched: Should nr_uninterruptible be decremented in ttwu_do_activate()?
    On 01/13/2012 01:08 AM, Rakib Mullick wrote:

    > On Thu, Jan 12, 2012 at 1:25 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
    >> On Thu, 2012-01-12 at 12:09 +0600, Rakib Mullick wrote:
    >>> On Wed, Jan 11, 2012 at 11:29 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
    >>>> On Wed, 2012-01-11 at 23:22 +0600, Rakib Mullick wrote:
    >>>>> Hello all,
    >>>>>
    >>>>> In ttwu_do_activate(), we're decrementing nr_uninterruptible if
    >>>>> p->sched_contributes_to_load (for SMP=y). But, we're also decrementing
    >>>>> nr_uninterruptible from activate_task at the same path. Why we're
    >>>>> doing it twice for a single task activation path?
    >>>>
    >>>> activate_task() does:
    >>>>
    >>>> if (task_contributes_to_load(p))
    >>>> rq->nr_uninterruptible--;
    >>>>
    >>>> Now task_contributes_to_load() reads like:
    >>>>
    >>>> #define task_contributes_to_load(task) \
    >>>> ((task->state & TASK_UNINTERRUPTIBLE) != 0 && \
    >>>> (task->flags & PF_FREEZING) == 0)
    >>>>
    >>>> which will be false, since we've set TASK_WAKING.
    >>>
    >>> Enough confusing. TASK_WAKING will be set when called from
    >>> try_to_wake_up(). ttwu_do_activate() gets called from other places:
    >>> scheduler_ipi() and sched_ttwu_pending() (at the time of cpu goes
    >>> down). TASK_WAKING will be not set at that time,
    >>
    >> Yes it will be, the only way to get on that list is throught
    >> ttwu_queue_remote() at which point tasks are TASK_WAKING.
    >>
    >>> moreover it is
    >>> possible that, task has p->sched_contributes_to_load is set and latter
    >>> on gets wake up by sched_ttwu_pending/scheduler_ipi() call.
    >>
    >> That's the entire point. But all ways to ttwu_queue_remote() explicitly
    >> set ->sched_contributes_to_load.
    >
    > That might be the case for scheduler_ipi(), but when
    > sched_ttwu_pending() gets called when a cpu goes down, all tasks from
    > wake_list of that cpu has been moved without TASK_WAKING is set. For a


    I think the task in rq->wake_list should already have state:TASK_WAKING,
    because it's a wake list.

    > particular task it might be possible that when it ran previously it
    > had p->sched_contributes_to_load is set. Latter, this task's cpu has
    > been put down and calls sched_ttwu_pending(), then for that task
    > p->sched_contributes_to_load is set and TASK_WAKING is not set.
    > Couldn't be happen?
    >
    > Thanks,
    > Rakib
    > --
    > 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: 2012-01-16 08:57    [W:0.027 / U:0.368 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site