From owner-freebsd-arch@FreeBSD.ORG Fri Mar 7 22:50:55 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F483106566C; Fri, 7 Mar 2008 22:50:55 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 33CE58FC1D; Fri, 7 Mar 2008 22:50:55 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m27MojhD042624; Fri, 7 Mar 2008 17:50:53 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Fri, 7 Mar 2008 12:53:26 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Kirk McKusick In-Reply-To: <200803071540.m27FeSU6096030@chez.mckusick.com> Message-ID: <20080307124455.Y920@desktop> References: <200803071540.m27FeSU6096030@chez.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Getting rid of the static msleep priority boost X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 22:50:55 -0000 On Fri, 7 Mar 2008, Kirk McKusick wrote: >> From: John Baldwin >> To: Jeff Roberson >> Date: Fri, 7 Mar 2008 08:42:37 -0500 >> Cc: arch@freebsd.org >> Subject: Re: Getting rid of the static msleep priority boost >> >> On Friday 07 March 2008 07:16:30 am Jeff Roberson wrote: >>> Hello, >>> >>> I've been studying some problems with recent scheduler improvements that >>> help a lot on some workloads and hurt on others. I've tracked the problem >>> down to static priority boosts handed out by msleep/cv_broadcastpri. >>> ... >> >> ... >> >> This change allows the decision on priority boost to be a scheduler >> decision to ignore it (so 4BSD could continue to do what it does now, >> but ULE may ignore it, or ignore certain levels, etc.) >> >> -- >> John Baldwin > > I strongly agree with John's suggestion. The 4BSD scheduler will continue > to have its historic behavior (which was `tuned' by careful selection of > priority boosts) while more sophisticated schedulers like ULE will be able > to use/ignore the priority boosts based on their better knowledge of system > behavior. Yes, this is a good point. 4BSD is starting to fall behind featurewise on SMP but we should try to keep it in good working order as it serves as an excellent point for comparison. Eventually as systems with more than 4 cores become standard we're going to have to make some decisions regarding its long term fate. One option would be for someone to keep the 4bsd priority scheduling code and couple it with the ULE per-cpu load balancing code to keep it going. However the global run-queue is seeing the end of its days. Thanks, Jeff > > Kirk McKusick >