From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 26 22:09:29 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E0FB6FB5; Tue, 26 Feb 2013 22:09:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C0824344; Tue, 26 Feb 2013 22:09:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1EEDCB96C; Tue, 26 Feb 2013 17:09:29 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: rtprio_thread trouble Date: Tue, 26 Feb 2013 15:29:24 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <1361559960.1185.81.camel@revolution.hippie.lan> In-Reply-To: <1361559960.1185.81.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302261529.24862.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Feb 2013 17:09:29 -0500 (EST) Cc: Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:09:29 -0000 On Friday, February 22, 2013 2:06:00 pm Ian Lepore wrote: > I ran into some trouble with rtprio_thread() today. I have a worker > thread that I want to run at idle priority most of the time, but if it > falls too far behind I'd like to bump it back up to regular timeshare > priority until it catches up. In a worst case, the system is > continuously busy and something scheduled at idle priority is never > going to run (for some definition of 'never'). > > What I found is that in this worst case, even after my main thread has > used rtprio_thread() to change the worker thread back to > RTP_PRIO_NORMAL, the worker thread never gets scheduled. This is with > the 4BSD scheduler but it appears that the same would be the case with > ULE, based on code inspection. I find that this fixes it for 4BSD, and > I think the same would be true for ULE... > > --- a/sys/kern/sched_4bsd.c Wed Feb 13 12:54:36 2013 -0700 > +++ b/sys/kern/sched_4bsd.c Fri Feb 22 11:55:35 2013 -0700 > @@ -881,6 +881,9 @@ sched_user_prio(struct thread *td, u_cha > return; > oldprio = td->td_user_pri; > td->td_user_pri = prio; > + if (td->td_flags & TDF_BORROWING && td->td_priority <= prio) > + return; > + sched_priority(td, prio); > } > > void > > But I'm not sure if this would have any negative side effects, > especially since in the ULE case there's a comment on this function that > specifically notes that it changes the the user priority without > changing the current priority (but it doesn't say why that matters). > > Is this a reasonable way to fix this problem, or is there a better way? This will lose the "priority boost" afforded to interactive threads when they sleep in the kernel in the 4BSD scheduler. You aren't supposed to drop the user priority to loose this boost until userret(). You could perhaps try only altering the priority if the new user pri is lower than your current priority (and then you don't have to check TDF_BORROWING I believe): if (prio < td->td_priority) sched_priority(td, prio); -- John Baldwin