scx_lavd: mitigate the lock holder preemption problem #779
Conversation
Trace the acquisition and release of blocking locks for kernel and fuxtexes for user-space. This is necessary to boost a lock holder task in terms of latency and time slice. We do not boost shared lock holders (e.g., read lock in rw_semaphore) since the kernel already prioritizes the readers over writers. Signed-off-by: Changwoo Min <[email protected]>
When a lock holder exhausts its time slide, it will be re-enqueued to a DSQ waiting for shceduling while holding a lock. In this case, prioritize its latency criticality proportionally, so a lock holder would be not stuck in a DSQ for a long time, improving system-wide progress. Signed-off-by: Changwoo Min <[email protected]>
When a task holds a lock, it should not yield its time slice or it should not be preempted out. In this way, we can mitigate harmful preemption of lock holders and reduce the total preemption counts. Signed-off-by: Changwoo Min <[email protected]>
Signed-off-by: Changwoo Min <[email protected]>
| { | ||
| if (taskc && cpuc) { | ||
| taskc->lock_boost++; | ||
| cpuc->lock_holder = is_lock_holder(taskc); |
There was a problem hiding this comment.
Can we assume this is always true, since taskc->lock_boost has been just incremented?
There was a problem hiding this comment.
taskc can be NULL if a task is not under scx, so it is necessary. Also, it is necessary to satisfy the verifier.
| * Reset task's lock and futex boost count | ||
| * for a lock holder to be boosted only once. | ||
| */ | ||
| reset_lock_futex_boost(taskc); |
There was a problem hiding this comment.
So if we reset the counter here, when the task releases the lock its counter will become negative? I'm wondering if a boolean logic would be simpler and accomplish the same, like acquire a lock => boost = true, release a lock => boost = false, and after using the boost => boost = false.
There was a problem hiding this comment.
Yes, the counter could become negative so the decrement logic test if the counter is positive before decrementing it.
I think using counter is necessary because a task can hold multiple locks.
|
Thanks @arighi for the review! |
If a task holding a lock (i.e., lock holder) is preempted for some reason, it will hinder the forward progress of a system and cause unnecessary task switches. To mitigate the lock holder preemption problem, this PR does the following:
In addition to the above major changes, this PR includes the bug fix in the preeemptability test (#773)
Overall this brings more consistent results with less preemption.