linux-kernel - Re: PROBLEM: Persistent unfair sharing of a processor by auto groups in 3.11-rc2 (has twice regressed)

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 26 Jul 2013 05:43:33 -0700
From:	Paul Turner <pjt@...gle.com>
To:	Max Hailperin <max@...tavus.edu>,
	LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: PROBLEM: Persistent unfair sharing of a processor by auto groups
 in 3.11-rc2 (has twice regressed)

>> Ah I see what's happening. Currently we only call update_cfs_shares()
>> from the enqueue/dequeue paths. However since your tasks never sleep and
>> cannot migrate they never pass this code. This in turns means that the
>> inter-cgroup relations (the shares) don't get updated.
>>
>> I think your patch would indeed be a correct minimal fix in that it adds
>> a share update to the regular tick path ensuring it gets done even in
>> the absence of enqueues/dequeues.

Hmm.. /me scratches head.

We definitely _used_ to have a call to update_cfs_shares() in
update_cfs_rq_blocked_load() for _exactly_ this reason.

Let's see... a-ha.

It was originally part of:
  f269ae0469fc882332bdfb5db15d3c1315fe2a10 sched: Update_cfs_shares at
period edge

But we reverted that right at the end of the merge window because the
amortization turned out to be too aggressive for interactive
workloads.  This happened in 17bc14b767cf0692420c43dbe5310ae98a5a7836.

Unfortunately, when we did that, we lost the call to update_cfs_shares().

Yes, this wants to be there.

Reviewed-by: Paul Turner <pjt@...gle.com>

For a description how about something like:

sched: ensure update_cfs_shares() is called for parents of
continuously-running tasks

We typically update a task_group's shares within the dequeue/enqueue
path.  However, continuously running tasks sharing a CPU are not
subject to these updates as they are only put/picked.  Unfortunately,
when we reverted f269ae046 (in 17bc14b7), we lost the augmenting
periodic update that was supposed to account for this; resulting in a
potential loss of fairness.

To fix this, re-introduce the explicit update in
update_cfs_rq_blocked_load() [called via entity_tick()].
--
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/