From owner-svn-src-head@FreeBSD.ORG Thu Mar 7 02:53:30 2013 Return-Path: Delivered-To: svn-src-head@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 42C5734B; Thu, 7 Mar 2013 02:53:30 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 04D649E8; Thu, 7 Mar 2013 02:53:30 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.6/8.14.6) with ESMTP id r272rT5t071791; Thu, 7 Mar 2013 02:53:29 GMT (envelope-from ian@svn.freebsd.org) Received: (from ian@localhost) by svn.freebsd.org (8.14.6/8.14.5/Submit) id r272rTUr071790; Thu, 7 Mar 2013 02:53:29 GMT (envelope-from ian@svn.freebsd.org) Message-Id: <201303070253.r272rTUr071790@svn.freebsd.org> From: Ian Lepore Date: Thu, 7 Mar 2013 02:53:29 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r247905 - head/sys/kern X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:53:30 -0000 Author: ian Date: Thu Mar 7 02:53:29 2013 New Revision: 247905 URL: http://svnweb.freebsd.org/changeset/base/247905 Log: Call sched_prio() to immediately change the priority of the thread in response to an rtprio_thread() call, when the priority is different than the old priority, and either the old or the new priority class is not RTP_PRIO_NORMAL (timeshare). The reasoning for the second half of the test is that if it's a change in timeshare priority, then the scheduler is going to adjust that priority in a way that completely wipes out the requested change anyway, so what's the point? (If that's not true, then allowing a thread to change its own timeshare priority would subvert the scheduler's adjustments and let a cpu-bound thread monopolize the cpu; if allowed at all, that should require priveleges.) On the other hand, if either the old or new priority class is not timeshare, then the scheduler doesn't make automatic adjustments, so we should honor the request and make the priority change right away. The reason the old class gets caught up in this is the very reason for this change: when thread A changes the priority of its child thread B from idle back to timeshare, thread B never actually gets moved to a timeshare-range run queue unless there are some idle cycles available to allow it to first get scheduled again as an idle thread. Reviewed by: jhb@ Modified: head/sys/kern/kern_resource.c Modified: head/sys/kern/kern_resource.c ============================================================================== --- head/sys/kern/kern_resource.c Wed Mar 6 23:22:40 2013 (r247904) +++ head/sys/kern/kern_resource.c Thu Mar 7 02:53:29 2013 (r247905) @@ -469,8 +469,7 @@ sys_rtprio(td, uap) int rtp_to_pri(struct rtprio *rtp, struct thread *td) { - u_char newpri; - u_char oldpri; + u_char newpri, oldclass, oldpri; switch (RTP_PRIO_BASE(rtp->type)) { case RTP_PRIO_REALTIME: @@ -493,11 +492,12 @@ rtp_to_pri(struct rtprio *rtp, struct th } thread_lock(td); + oldclass = td->td_pri_class; sched_class(td, rtp->type); /* XXX fix */ oldpri = td->td_user_pri; sched_user_prio(td, newpri); - if (td->td_user_pri != oldpri && (td == curthread || - td->td_priority == oldpri || td->td_user_pri <= PRI_MAX_REALTIME)) + if (td->td_user_pri != oldpri && (oldclass != RTP_PRIO_NORMAL || + td->td_pri_class != RTP_PRIO_NORMAL)) sched_prio(td, td->td_user_pri); if (TD_ON_UPILOCK(td) && oldpri != newpri) { critical_enter();