Messages in this thread | | | Date | Wed, 05 Mar 2014 18:22:12 -0700 | From | Khalid Aziz <> | Subject | Re: [RFC] [PATCH] Pre-emption control for userspace |
| |
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.
> 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
| |