linux-kernel - Re: [RFC 4/8] Improve the tracking of active utilisation

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: <20160128122100.GD6357@twins.programming.kicks-ass.net>
Date:	Thu, 28 Jan 2016 13:21:00 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	luca abeni <luca.abeni@...tn.it>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Juri Lelli <juri.lelli@....com>
Subject: Re: [RFC 4/8] Improve the tracking of active utilisation

On Thu, Jan 28, 2016 at 12:14:41PM +0100, luca abeni wrote:
> I am looking at the PI stuff right now... And I am not sure if
> SCHED_DEADLINE does the right thing for PI :)

Strictly speaking it does not, dl-pi is a giant hack.

Some day we should fix this :-)

But as you might be aware, SMP capable PI protocols for this are
somewhat tricky.

> Anyway, I think the total SCHED_DEADLINE utilization (rd->dl_bw) is
> currently not changed when a SCHED_OTHER task is boosted to
> SCHED_DEADLINE due to PI... Right? 

>From memory that is accurate, but not right as per the above. Ideally we
would indeed charge the boosted task against the booster's bandwidth.

This has the 'fun' consequence that while you deplete the bandwidth of
the booster the PI order can change and we should pick another booster
etc.

> Is this the desired behaviour?

Nope, but fixing this is likely to be non-trivial.