Noticable Delays Since Beta 3 (possible cause)
Matthew Dillon
dillon at apollo.backplane.com
Mon Oct 11 08:37:43 PDT 2004
I would not recommend putting proc0 wakeup code in your time-critical
critical section code. It's a terrible hack and an abuse of the purpose
of the critical section code and right smack in the middle of a very
important critical path that effects the performance of the *entire*
system.
I would also not recommend having a TDP_WAKEPROC0 flag for curproc,
that's a terrible hack and a misplaced flag (the flag, if you have one
at all, should be global or per-cpu, and certainly *NOT* placed in
the current thread's flagset!).
It seems to me the proper solution is to use the same codepath that
woke up proc0 originally (in 4.x), which in 5.x/6.x has now become
sleepq_broadcast(). Check to see if proc0 needs to be woken up there,
in the code that moves the threads from the sq to the temporary list,
and if one of them needs proc0 just flag it and then lock whatever
sleepq list proc0 is on and pull it off too before you hit the
sleepq_resume_thread() loop.
-Matt
More information about the freebsd-current
mailing list