linux-kernel - Re: [PATCH] Revert "sched/fair: Fix O(nr_cgroups) in the load balancing path"

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191029153615.GP4114@hirez.programming.kicks-ass.net>
Date:   Tue, 29 Oct 2019 16:36:15 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Doug Smythies <dsmythies@...us.net>
Cc:     'Vincent Guittot' <vincent.guittot@...aro.org>,
        'linux-kernel' <linux-kernel@...r.kernel.org>,
        "'open list:THERMAL'" <linux-pm@...r.kernel.org>,
        'Ingo Molnar' <mingo@...nel.org>,
        'Linus Torvalds' <torvalds@...ux-foundation.org>,
        'Thomas Gleixner' <tglx@...utronix.de>,
        'Sargun Dhillon' <sargun@...gun.me>,
        'Tejun Heo' <tj@...nel.org>, 'Xie XiuQi' <xiexiuqi@...wei.com>,
        xiezhipeng1@...wei.com,
        'Srinivas Pandruvada' <srinivas.pandruvada@...ux.intel.com>,
        'Rik van Riel' <riel@...riel.com>
Subject: Re: [PATCH] Revert "sched/fair: Fix O(nr_cgroups) in the load
 balancing path"

On Tue, Oct 29, 2019 at 07:55:26AM -0700, Doug Smythies wrote:

> I only know that the call to the intel_pstate driver doesn't
> happen, and that it is because cfs_rq_is_decayed returns TRUE.
> So, I am asserting that the request is not actually decayed, and
> should not have been deleted.

So what cfs_rq_is_decayed() does is allow a cgroup's cfs_rq to be
removed from the list.

Once it is removed, that cfs_rq will no longer be checked in the
update_blocked_averages() loop. Which means done has less chance of
getting false. Which in turn means that it's more likely
rq->has_blocked_load becomes 0.

Which all sounds good.

Can you please trace what keeps the CPU awake?

> Now, if we also look back at the comments for the original commit:
> 
> 	"In an edge case where temporary cgroups were leaking, this
> 	caused the kernel to consume good several tens of percents of
> 	CPU cycles running update_blocked_averages(), each run taking
> 	multiple millisecs."
> 
> To my way of thinking: Fix the leak, don't program around it; The
> commit breaks something else, so revert it.

The leak was fixed, but it still doesn't make sense to keep idle cgroups
on that list. Some people have a stupid amount of cgroups, most of which
are pointless and unused, so being able to remove them is good.

Which is why it got added back, once list management issues were sorted.