Date: Mon, 11 Oct 2004 08:37:38 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Sam Lawrance <boris@brooknet.com.au> Cc: David Xu <davidxu@freebsd.org> Subject: Re: Noticable Delays Since Beta 3 (possible cause) Message-ID: <200410111537.i9BFbca1084688@apollo.backplane.com> References: <Pine.NEB.3.96L.1041011045403.31040K-100000@fledge.watson.org> <1097500052.2797.10.camel@dirk.no.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410111537.i9BFbca1084688>