lkml.org 
[lkml]   [2010]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5/6] futex: handle timeout inside adaptive lock spin
>>> On 4/7/2010 at 01:31 PM, in message <4BBCC174.7020409@us.ibm.com>, Darren Hart
<dvhltc@us.ibm.com> wrote:
> Thomas Gleixner wrote:
>> On Mon, 5 Apr 2010, Darren Hart wrote:
>>
>>> Signed-off-by: Darren Hart <dvhltc@us.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





\
 
 \ /
  Last update: 2010-04-07 20:47    [W:0.065 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site