Date: Sun, 12 Dec 2010 08:39:18 +1100 From: Peter Jeremy <peterjeremy@acm.org> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Realtime thread priorities Message-ID: <20101211213918.GB21959@server.vk2pj.dyndns.org> 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
[-- Attachment #1 --] On 2010-Dec-10 10:50:45 -0500, John Baldwin <jhb@freebsd.org> wrote: >The problem I am running into is that when a time-sharing thread goes to sleep >in the kernel (waiting on select, socket data, tty, etc.) it actually ends up >in the kernel priorities range (64 - 127). This means when it wakes up it >will trump (and preempt) a real-time user thread even though these processes >nominally have a priority down in the 160 - 223 range. We do drop the kernel >sleep priority during userret(), but we don't recheck the scheduler queues to >see if we should preempt the thread during userret(), so it effectively runs >with the kernel sleep priority for the rest of the quantum while it is in >userland. This may also explain the situation I'm seeing where idprio processes are receiving more than "idle" time (see "idprio processes slowing down system" in -hackers). >My first question is if this behavior is the desired behavior? Originally I >think I preferred the current layout because I thought a thread in the kernel >should always have priority so it can release locks, etc. I suspect it was intended as a solution to priority inversion issues. >1) (easy) just move the real-time priority range above the kernel sleep >priority range This won't affect the associated issue of idprio processes "preempting" timesharing processes. >2) (harder) make sched_userret() check the run queue to see if it should >preempt when dropping the kernel sleep priority. IMHO, this is the "correct" solution but that needs to be tempered by the additional overhead this might incur. -- Peter Jeremy [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk0D74YACgkQ/opHv/APuIcROACeNr2ajW+rBdeMeZ+kVJAJoftB xtMAnAv9ZBzEYKvf/r67onBgf/dNZhGl =6FHd -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101211213918.GB21959>