Date: Mon, 13 Dec 2010 09:38:04 -0500 From: John Baldwin <jhb@freebsd.org> To: Peter Jeremy <peterjeremy@acm.org> Cc: arch@freebsd.org Subject: Re: Realtime thread priorities Message-ID: <201012130938.04746.jhb@freebsd.org> In-Reply-To: <20101211213918.GB21959@server.vk2pj.dyndns.org> References: <201012101050.45214.jhb@freebsd.org> <20101211213918.GB21959@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, December 11, 2010 4:39:18 pm Peter Jeremy wrote: > 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). Yes, this likely does explain that. We could fix that for just idle priority class threads in sched_userret() easily enough (just call mi_switch() if td->td_pri_class == PRI_CLASS_IDLE). > >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. The other concern (and reason I lean towards 1) is that this is also a feature that we depend on to favor interactive threads over compute-bound threads. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012130938.04746.jhb>