linux-kernel - Re: [PATCH 5/6] futex: handle timeout inside adaptive lock spin

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:	Wed, 07 Apr 2010 12:44:11 -0600
From:	"Gregory Haskins" <ghaskins@...ell.com>
To:	"Thomas Gleixner" <tglx@...utronix.de>,
	"Darren Hart" <dvhltc@...ibm.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Eric Dumazet" <eric.dumazet@...il.com>,
	"Steven Rostedt" <rostedt@...dmis.org>,
	"Peter Zijlstra" <peterz@...radead.org>,
	"Peter Morreale" <PMorreale@...ell.com>,
	"Sven Dietrich" <SDietrich@...ell.com>,
	"Chris Mason" <chris.mason@...cle.com>,
	"Avi Kivity" <avi@...hat.com>, "Rik van Riel" <riel@...hat.com>,
	"Chris Wright" <chrisw@...s-sol.org>,
	"John Cooper" <john.cooper@...rd-harmonic.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/6] futex: handle timeout inside adaptive lock
	 spin

>>> On 4/7/2010 at 01:31 PM, in message <4BBCC174.7020409@...ibm.com>, Darren Hart
<dvhltc@...ibm.com> wrote: 
> Thomas Gleixner wrote:
>> On Mon, 5 Apr 2010, Darren Hart wrote:
>> 
>>> Signed-off-by: Darren Hart <dvhltc@...ibm.com>

>>> +		if (timeout) {
>>> +			now = ktime_get();
>> 
>>   Hmm. Calling that in every iteration might hurt especially on non
>>   TSC systems, but well...
> 
> I haven't come across a better alternative since arming the timer before 
> setting TASK_INTERRUPTIBLE isn't appropriate.

Hey Darren,

I remember we tried something similar in early versions of the adaptive locks and this was definitely bad. :(

It ended up putting so much contention on the xtime_lock (IIRC) that it resulted in adaptive locks hurting overall performance verses not using adaptive at all.  Alternative mechanisms employed a hybrid where the inner loops used a pseudo calibrated counter loop, and the outer loop checks periodically against a real clock.  It all plays into "you are burning CPU cycles anyway, so might as well put them to use" theory.  Hacky, yes, but it did relieve the pressure on the time subsystem locks and freed up a _lot_ of performance.  Without this, the concept of timeouts+adaptive was unworkable.  I think Steven ultimately rejected the timeout related patches outright when he merged adaptive to -rt, but I think Sven pulled them into SLERT if you would like a potential code reference to a working solution.

-Greg

--
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/