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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 12 May 2017 16:36:31 +0200
From:   Vincent Guittot <>
To:     Tejun Heo <>
Cc:     Ingo Molnar <>,
        Peter Zijlstra <>,
        linux-kernel <>,
        Linus Torvalds <>,
        Mike Galbraith <>, Paul Turner <>,
        Chris Mason <>,
Subject: Re: [PATCH v2 for-4.12-fixes 2/2] sched/fair: Fix O(# total cgroups)
 in load balance path

On 12 May 2017 at 15:16, Tejun Heo <> wrote:
> Hello, Vincent.
> On Thu, May 11, 2017 at 09:02:22AM +0200, Vincent Guittot wrote:
>> Sorry, what i mean is:
>> When the group entity of a cfs_rq is enqueued, we are sure that either
>> the parents is already enqueued or it will be enqueued in the same
>> sequence. We must be sure that no other branch will be enqueued in the
>> middle of the sequence and will reset tmp_alone_branch.
>> This is true with current implementation but I  wondered it can happen
>> if we del/add the cfs_rq out of order
>> That said i haven't find a use case that break the sequence
> Hmm... a cfs_rq can be removed from leaf list iff it's empty and
> dequeued, and enqueueing is always from top down.  If an ancestor is
> already enqueued, it's guaranteed to be on the leaf list; otherwise,
> it's guaranteed to be enqueued beforehand and thus put on the leaf
> list too.  I think it should be fine.

I agree

Acked-by: Vincent Guittot <>

> Thanks.
> --
> tejun

Powered by blists - more mailing lists