From owner-freebsd-arch@FreeBSD.ORG Tue Sep 28 02:27:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD8BF16A4CE for ; Tue, 28 Sep 2004 02:27:54 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 358A543D3F for ; Tue, 28 Sep 2004 02:27:54 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 17397 invoked by uid 89); 28 Sep 2004 02:27:52 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 28 Sep 2004 02:27:52 -0000 Received: (qmail 17357 invoked by uid 89); 28 Sep 2004 02:27:52 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 28 Sep 2004 02:27:52 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8S2Rqmt005983; Mon, 27 Sep 2004 22:27:52 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <41588FC5.6090203@elischer.org> References: <1096133353.53798.17613.camel@palm.tree.com> <200409271016.13345.jhb@FreeBSD.org> <1096305626.95152.163.camel@palm.tree.com> <200409271443.22667.jhb@FreeBSD.org><41588FC5.6090203@elischer.org> Content-Type: text/plain Message-Id: <1096338471.3733.254.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 27 Sep 2004 22:27:51 -0400 Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" Subject: Re: sched_userret priority adjustment patch for sched_4bsd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 02:27:54 -0000 On Mon, 2004-09-27 at 18:10, Julian Elischer wrote: > Stephan Uphoff wrote: > > >On Mon, 2004-09-27 at 14:43, John Baldwin wrote: > > > > > >>>>@@ -272,7 +272,7 @@ > >>>> { > >>>> > >>>> mtx_assert(&sched_lock, MA_OWNED); > >>>>- if (td->td_priority < curthread->td_priority) > >>>>+ if (td->td_priority < curthread->td_ksegrp->kg_user_pri) > >>>> curthread->td_flags |= TDF_NEEDRESCHED; > >>>> } > >>>> > >>>> > > in sched_userret() we do: > kg = td->td_ksegrp; > if (td->td_priority != kg->kg_user_pri) { > mtx_lock_spin(&sched_lock); > td->td_priority = kg->kg_user_pri; > mtx_unlock_spin(&sched_lock); > } > > but we don't actually take any action in the case where the thread is > heading out to userland with > a priority of less importance than a waiting thread. That happens in > AST() where we also set it down > but only in the case of TDF_NEEDRESCHED being set. > > it would make more sense to ALWAYS to the TDF_NEEDRESCHED clause, in > userret() > based on the user priority... i.e. the priority would be reduced going > to userland. > Unfortunatly this would stop one of the reasons to for priorityu > raisning in BSD. > > The priority of a thread that waits for IO is raised not only to make it > start again in the kernel > as an interactive thread, but also so that it can run into userland too > and get some priority > for actually USING the new data/input.. Thanks - I wasn't aware of this. Isn't there a high potential for abuse? A client/server programs constantly refreshing priority by waiting for requests/replies comes to mind. If a client/server pair constantly talks to each other they could eat a lot of cpu time. I have to think about this some more. Stephan