Page MenuHomeFreeBSD

Reduce umtx-related work on exec and exit
ClosedPublic

Authored by mjg on May 4 2019, 10:38 PM.
Tags
None
Referenced Files
F103548257: D20160.diff
Tue, Nov 26, 9:29 AM
Unknown Object (File)
Mon, Nov 18, 1:08 PM
Unknown Object (File)
Sun, Nov 17, 8:29 PM
Unknown Object (File)
Sep 4 2024, 8:08 PM
Unknown Object (File)
Sep 4 2024, 12:14 PM
Unknown Object (File)
Aug 31 2024, 4:44 AM
Unknown Object (File)
Aug 30 2024, 7:39 PM
Unknown Object (File)
Aug 30 2024, 7:39 PM
Subscribers

Details

Summary

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.

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.

  • remove proc locking in the first place
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.

kib added inline comments.
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);
  ...
This revision is now accepted and ready to land.May 8 2019, 8:16 AM
sys/kern/sched_ule.c
1871

I wanted to keep this easier to modify should extra code be needed in the future.

This revision was automatically updated to reflect the committed changes.