lkml.org 
[lkml]   [2014]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] [PATCH] Pre-emption control for userspace
On Wed, 5 Mar 2014, Khalid Aziz wrote:

> On 03/05/2014 04:59 PM, David Lang wrote:
>> what's the cost to setup mmap of this file in /proc. this is sounding
>> like a lot of work.
>
> That is a one time cost paid when a thread initializes itself.
>
>>
>>>> is this gain from not giving up the CPU at all? or is it from avoiding
>>>> all the delays due to the contending thread trying in turn? the
>>>> yield_to() approach avoids all those other threads trying in turn so it
>>>> should get fairly close to the same benefits.
>>>>
>>>
>>> The gain is from avoiding contention by giving locking thread a chance
>>> to complete its critical section which is expected to be very short
>>> (certainly shorter than timeslice). Pre-emption immunity gives it one
>>> and only one additional timeslice.
>>
>> but the yield_to() does almost the same thing, there is a small bump,
>> but you don't have to wait for thread B to spin, thread C..ZZZ etc to
>> spin before thread A can finish it's work. As soon as the second thread
>> hits the critical section, thread A is going to be able to do more work
>> (and hopefully finish)
>>
>>> Hope this helps clear things up.
>>
>> It doesn't sound like you and I are understanding how the yield_to()
>> approach would work. I hope my comments have helped get us on the same
>> page.
>>
>
> I apologize if I am being dense. My understanding of yield_to() is what Oleg
> had said in his reply earlier, so I will quote the example he gave:
>
> my_lock()
> {
> if (!TRY_LOCK()) {
> yield_to(owner);
> LOCK();
> }
>
> owner = gettid();
> }
>
> If thread A had already lost the processor by the time thread B executes
> above code, wouldn't we have paid the price of two context switches for
> thread A?

Yes, you pay for two context switches, but you don't pay for threads B..ZZZ all
running (and potentially spinning) trying to aquire the lock before thread A is
able to complete it's work.

As soon as a second thread hits the contention, thread A gets time to finish.

It's not as 'good' [1] as thread A just working longer, but it's FAR better than
thread A sleeping while every other thread runs and potentially tries to get the
lock

[1] it wastes the context switches, but it avoids the overhead of figuring out
if the thread needs to extend it's time, and if it's time was actually extended,
and what penalty it should suffer the next time it runs....

I expect that in practice, it will be very close to the 'theoretical ideal' of
"I'm doing something important, don't interrupt me", without all the potential
abuse of such a flag.

David Lang


\
 
 \ /
  Last update: 2014-03-06 02:21    [W:0.236 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site