Date: Fri, 10 Dec 2010 18:26:31 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Realtime thread priorities Message-ID: <20101210162631.GC33073@deviant.kiev.zoral.com.ua> In-Reply-To: <201012101050.45214.jhb@freebsd.org> References: <201012101050.45214.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--BYl/BInBdgsQr4gH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 10, 2010 at 10:50:45AM -0500, John Baldwin wrote: > So I finally had a case today where I wanted to use rtprio but it doesn't= seem=20 > very useful in its current state. Specifically, I want to be able to tag= =20 > certain user processes as being more important than any other user proces= ses=20 > even to the point that if one of my important processes blocks on a mutex= , the=20 > owner of that mutex should be more important than sshd being woken up fro= m=20 > sbwait by new data (for example). This doesn't work currently with rtpri= o due=20 > to the way the priorities are laid out (and I believe I probably argued f= or=20 > the current layout back when it was proposed). >=20 > The current layout breaks up the global thread priority space (0 - 255) i= nto a=20 > couple of bands: >=20 > 0 - 63 : interrupt threads > 64 - 127 : kernel sleep priorities (PSOCK, etc.) > 128 - 159 : real-time user threads (rtprio) > 160 - 223 : time-sharing user threads > 224 - 255 : idle threads (idprio and kernel idle procs) >=20 > The problem I am running into is that when a time-sharing thread goes to = sleep=20 > in the kernel (waiting on select, socket data, tty, etc.) it actually end= s up=20 > in the kernel priorities range (64 - 127). This means when it wakes up i= t=20 > will trump (and preempt) a real-time user thread even though these proces= ses=20 > nominally have a priority down in the 160 - 223 range. We do drop the ke= rnel=20 > sleep priority during userret(), but we don't recheck the scheduler queue= s to=20 > see if we should preempt the thread during userret(), so it effectively r= uns=20 > with the kernel sleep priority for the rest of the quantum while it is in= =20 > userland. >=20 > My first question is if this behavior is the desired behavior? Originall= y I=20 > think I preferred the current layout because I thought a thread in the ke= rnel=20 > should always have priority so it can release locks, etc. However, prior= ity=20 > propagation should actually handle the case of some very important thread= =20 > needing a lock. In my use case today where I actually want to use rtprio= I=20 > think I want different behavior where the rtprio thread is more important= than=20 > the thread waking up with PSOCK, etc. >=20 > If we decide to change the behavior I see two possible fixes: >=20 > 1) (easy) just move the real-time priority range above the kernel sleep= =20 > priority range >=20 > 2) (harder) make sched_userret() check the run queue to see if it should= =20 > preempt when dropping the kernel sleep priority. I think bde@ has sugges= ted=20 > that we should do this for correctness previously (and I've had some old,= =20 > unfinished patches to do this in a branch in p4 for several years). Would not doing #2 allow e.g. two threads that perform ping-pong with a single byte read/write into a socket to usurp the CPU ? The threads could try to also do some CPU-intensive calculations for some time during the quantum too. Such threads are arguably "interactive", but I think that the gain is priority is too unfair. --BYl/BInBdgsQr4gH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0CVLYACgkQC3+MBN1Mb4hzagCg3w/7+CjRXYLwf/MNvYtKet3E x9AAoKAmUetMkWLgsi+55nF6/t8m2767 =xQAV -----END PGP SIGNATURE----- --BYl/BInBdgsQr4gH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101210162631.GC33073>