lkml.org 
[lkml]   [2014]   [Mar]   [6]   [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 05:36 PM, David Lang wrote:
>> 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.
>>
>
> Ah, great. We are converging now.
>
>> As soon as a second thread hits the contention, thread A gets time to
>> finish.
>
> Only as long as thread A could be scheduled immediately which may or may not
> be the case depending upon what else is running on the core thread A last ran
> on and if thread A needs to be migrated to another core.
>
>>
>> It's not as 'good' [1] as thread A just working longer,
>
> and that is the exact spot where I am trying to improve performance.

well, you have said that the "give me more time" flag results in 3-5% better
performance for databases under some workloads, how does this compare with the
results of yield_to()?

I think that the two approaches are going to be very close. I'd lay good odds
that the difference between the two is very hard to extract from the noise of
the variation of different runs (I won't say statistically insignificant, but I
will say that I expect it to take a lot of statistical analysis to pull it out
of the clutter)

David Lang

>> but it's FAR
>> better than thread A sleeping while every other thread runs and
>> potentially tries to get the lock
>
> Absolutely. I agree with that.
>
>>
>> [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....
>
> All of it can be done by setting and checking couple of flags in task_struct.
> That is not insignificant, but hardly expensive. Logic is quite simple:
>
> resched()
> {
> ........
> if (immmunity) {
> if (!penalty) {
> immunity = 0;
> penalty = 1;
> -- skip context switch --
> }
> else {
> immunity = penalty = 0;
> -- do the context switch --
> }
> }
> .........
> }
>
> sched_yield()
> {
> ......
> penalty = 0;
> ......
> }
>
> This simple logic will also work to defeat the obnoxius threads that keep
> setting immunity request flag repeatedly within the same critical section to
> give themselves multiple extensions.
>
> Thanks,
> Khalid
>


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