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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 28 Jan 2016 14:41:29 +0100
From:	luca abeni <luca.abeni@...tn.it>
To:	Peter Zijlstra <peterz@...radead.org>
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

Hi Peter,

On Thu, 28 Jan 2016 13:21:00 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> 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 :-)
I am trying to have a better look at the code, and I think that
implementing bandwidth inheritance (BWI) could be easy (implementing
M-BWI, that can be analyzed on multi-processor systems, is more complex
because it requires busy waiting or similar).


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


> > 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.
Yes, this would be the BWI approach


> 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.
Ok... So, if this is acceptable for this patchset I'll try to keep the
current PI behaviour, and I'll try to have a look at a better PI
protocol after the runtime reclaiming stuff is done (that is, I make it
acceptable for mainline, or we decide that a different approach is
needed).



			Luca