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]

Date:	Thu, 28 Jan 2016 22:15:32 +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

On Thu, 28 Jan 2016 15:00:53 +0100
Peter Zijlstra <peterz@...radead.org> wrote:
> On Thu, Jan 28, 2016 at 02:41:29PM +0100, luca abeni wrote:
> 
> > > 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).
> 
> Ah indeed, I remember now. To which I said that if busy-waiting is
> 'correct' so then must not busy-waiting be, for that consumes less
> cputime and would allow more actual work to be done.
The issue is that when the task wakes up after blocking, the scheduler
has to check if the current deadline and runtime can still be used (and
if they cannot, it generates a new deadline).
Of course a blocking solution can work, but the strategy used to check
if deadline and runtime are still valid must be changed. I discussed
this with the M-BWI authors about one year ago, but we did not arrive
to a definitive conclusion.

Anyway, I suspect that implementing BWI (without the "M-"), which has
no busy-waiting, could be an improvement respect to the current
mechanism.


			Thanks,
				Luca

> 
> Of course, I might have missed some subtle detail, but intuition
> suggests the above.
> 
> > > 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,
> 
> Yeah that's fine. That's decidedly outside the scope of these patches.
> 
> > 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).
> 
> That would be very nice indeed!