From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 19:06:11 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65920F8C for ; Fri, 22 Feb 2013 19:06:11 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2E45B35B for ; Fri, 22 Feb 2013 19:06:10 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1MJ62Rp064165 for ; Fri, 22 Feb 2013 12:06:02 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1MJ60eW054816 for ; Fri, 22 Feb 2013 12:06:00 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: rtprio_thread trouble From: Ian Lepore To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Feb 2013 12:06:00 -0700 Message-ID: <1361559960.1185.81.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit 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: Fri, 22 Feb 2013 19:06:11 -0000 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? -- Ian