Vast majority of the time there is no need to do anything. The patch below avoids relocking proc and locking umtx + thread lock in the common case.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 24109
Event Timeline
sys/kern/kern_umtx.c | ||
---|---|---|
4422 | So your problem is this PROC_UNLOCK() ? I think it can be done much simpler. Since the process is single-threaded, its thread list must be stable there and you can avoid acquiring the PROC_LOCK() in umtx_exec_hook at all. Of course the proper comment is due. |
sys/kern/kern_umtx.c | ||
---|---|---|
4422 | I'm after avoidable locks in general. umtx shows up as a minor global lock in the grand scheme of things, I don't see what's the problem plugging it. |
sys/kern/sched_ule.c | ||
---|---|---|
1871 | Why not write this part as if (td->td_lend_user_pri == prio || td->td_user_pri == min(prio, td->td_base_user_pri) || td->td_priority < td->td_user_pri) return; thread_lock(td); ... |
sys/kern/sched_ule.c | ||
---|---|---|
1871 | I wanted to keep this easier to modify should extra code be needed in the future. |