From owner-freebsd-arch@FreeBSD.ORG Wed Sep 29 14:39:01 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 839DA16A4CF for ; Wed, 29 Sep 2004 14:39:01 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id E793643D48 for ; Wed, 29 Sep 2004 14:39:00 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 5008 invoked by uid 89); 29 Sep 2004 14:38:56 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 29 Sep 2004 14:38:56 -0000 Received: (qmail 4937 invoked by uid 89); 29 Sep 2004 14:38:55 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 29 Sep 2004 14:38:55 -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 i8TEcsmt015285; Wed, 29 Sep 2004 10:38:54 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: John Baldwin In-Reply-To: <200409281056.00870.jhb@FreeBSD.org> References: <1096133353.53798.17613.camel@palm.tree.com> <200409271443.22667.jhb@FreeBSD.org> <1096320486.3733.58.camel@palm.tree.com> <200409281056.00870.jhb@FreeBSD.org> Content-Type: text/plain Message-Id: <1096468734.3733.1177.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 29 Sep 2004 10:38:54 -0400 Content-Transfer-Encoding: 7bit cc: Julian Elischer 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: Wed, 29 Sep 2004 14:39:01 -0000 On Tue, 2004-09-28 at 10:56, John Baldwin wrote: > If A has a priority boost from tsleep() this is intentional, however. The > priroity boosts from tsleep() are _supposed_ to do this so as to favor > interactive tasks. Note that if you add the code to always raise td_priority > while in the kernel as below you may end up defeating this well-known feature > of the 4BSD scheduler. OK - you and Julian convinced me that this is a feature that I should have known about. Without test cases or interactivity benchmarks discussions if this is still a desirable feature are probably useless. I will revisit the this once test cases materialize or I have time to think about a benchmark (Not likely anytime soon). Stephan