lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 16 Jan 2012 14:27:47 +0600 From: Rakib Mullick <rakib.mullick@...il.com> To: Michael Wang <wangyun@...ux.vnet.ibm.com> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>, Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [Question] sched: Should nr_uninterruptible be decremented in ttwu_do_activate()? On Mon, Jan 16, 2012 at 1:53 PM, Michael Wang <wangyun@...ux.vnet.ibm.com> wrote: > On 01/13/2012 01:08 AM, Rakib Mullick wrote: > >> On Thu, Jan 12, 2012 at 1:25 PM, Peter Zijlstra <a.p.zijlstra@...llo.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@...llo.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. > But, what I got by means of TASK_WAKING is this task is about to RUN, very soon it'll have TASK_RUNNING state. And, if I hadn't miss any portion of code, then rq->wake_list doesn't have TASK_WAKING state. Thanks, Rakib -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists