Messages in this thread | | | Date | Fri, 09 Apr 2010 01:52:02 -0400 | From | john cooper <> | Subject | Re: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptive spinning |
| |
Darren Hart wrote: > john cooper wrote: >> But here we're otherwise completely >> open to indiscriminate scheduling preemption even though >> we may be holding a userland lock. > > That's true with any userland lock.
Agreed. However from your earlier mail it seemed addressing this scenario was within the scope of consideration.
There are two ways to deal with this condition, either reactive in the sense we do so after the lock holder has been preempted and subsequently find we're spinning in sibling thread context attempting to acquire the lock. Or proactively where we provide a time bounded deferral of lock holder preemption with the assumption the lock hold path overhead has negligible effect upon deferring a potentially coincident scheduling operation.
It is fairly straightforward to demonstrate the impact to performance with a focused micro benchmark, less so for a more "typical" application with the effect being diluted among other app activity.
The two approaches are complimentary with differing system wide tradeoffs. Both require some insight into the scheduling disposition of the lock holder, the preemption deferral mechanism more so. If a scheme to expose scheduler state transitions to (or cooperate with) userland locking primitives is being considered, it seems opportune to consider support as well for this scenario.
-john
-- john.cooper@redhat.com
| |