linux-kernel - Re: [PATCH v2 2/3] sched/fair: prevent cpu burst too many periods

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]

Message-ID: <YbH/6H+QtjFlw+19@hirez.programming.kicks-ass.net>
Date:   Thu, 9 Dec 2021 14:08:56 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Honglei Wang <wanghonglei@...ichuxing.com>
Cc:     Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        linux-kernel@...r.kernel.org,
        Huaixin Chang <changhuaixin@...ux.alibaba.com>,
        Honglei Wang <jameshongleiwang@....com>
Subject: Re: [PATCH v2 2/3] sched/fair: prevent cpu burst too many periods

On Wed, Dec 08, 2021 at 10:50:38PM +0800, Honglei Wang wrote:
> Tasks might get more cpu than quota in persistent periods due to the
> cpu burst introduced by commit f4183717b370 ("sched/fair: Introduce the
> burstable CFS controller").

> For example, one task group whose quota is
> 100ms per period and can get 100ms burst, and its avg utilization is
> around 105ms per period.

That would be a mis-configuration, surely..

> Once this group gets a free period which
> leaves enough runtime, it has a chance to get computting power more
> than its quota for 10 periods or more in common bandwidth configuration
> (say, 100ms as period).

Sure, if it, for some miraculous reason, decides to sleep for a whole
period and then resume, it can indeed consume up to that 100ms extra,
which, if as per the above, done at 5ms per perios, would be 20 periods
until depleted.

> It means tasks can 'steal' the bursted power to
> do daily jobs because all tasks could be scheduled out or sleep to help
> the group get free periods.

That's the design,,

> I believe the purpose of cpu burst is to help handling bursty worklod.
> But if one task group can get computting power more than its quota for
> persistent periods even there is no bursty workload, it's kinda broke.

So if that was were bursty, it could consume that 100ms extra in a
single go and that would be fine, but spreading that same amount over 20
periods is somehow a problem? -- even though the interference is less.

> This patch limits the burst to 2 periods so that it won't break the
> quota limit for long. Permitting 2 periods can help on the scenario that
> periods refresh lands in the middle of a burst workload. With this, we
> can give task group more cpu burst power to handle the real burst
> workload and don't worry about the 'stealing'.

I've yet so see an actual reason for any of this...