From owner-cvs-all@FreeBSD.ORG Sat Nov 11 16:22:56 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83D5216A412; Sat, 11 Nov 2006 16:22:56 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 188C943D4C; Sat, 11 Nov 2006 16:22:56 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id AF2C05A1ED3; Sun, 12 Nov 2006 03:22:54 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id AD63B2741C; Sun, 12 Nov 2006 03:22:53 +1100 (EST) Date: Sun, 12 Nov 2006 03:22:52 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Xu In-Reply-To: <200611111311.kABDBVNH042993@repoman.freebsd.org> Message-ID: <20061112031308.I69769@delplex.bde.org> References: <200611111311.kABDBVNH042993@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern sched_4bsd.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 16:22:56 -0000 On Sat, 11 Nov 2006, David Xu wrote: > davidxu 2006-11-11 13:11:30 UTC > > FreeBSD src repository > > Modified files: > sys/kern sched_4bsd.c > Log: > Unbreak userland priority inheriting in NO_KSE case. Is this what made the non-KSE case unusable? At least with the load average bug fixed, it gave very unfair scheduling, and would only start about 4 concurrent hog processes on a 2-way SMP system. Improvements in some benchmarks may have depended on the bugs. Maybe a random load average is optimal for some loads :-). Bruce