From owner-cvs-all@FreeBSD.ORG Mon Mar 3 12:16:04 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59C081065670; Mon, 3 Mar 2008 12:16:04 +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 2071A8FC17; Mon, 3 Mar 2008 12:16:04 +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 m23CFnDb023888; Mon, 3 Mar 2008 07:15:59 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Mon, 3 Mar 2008 02:18:05 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Julian Elischer In-Reply-To: <47CB81BB.1080009@elischer.org> Message-ID: <20080303021658.L920@desktop> References: <200803020821.m228L0Yw042389@repoman.freebsd.org> <20080301222513.Y920@desktop> <20080302105958.GF67687@server.vk2pj.dyndns.org> <47CB81BB.1080009@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/kern sched_ule.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: Mon, 03 Mar 2008 12:16:04 -0000 On Sun, 2 Mar 2008, Julian Elischer wrote: > Peter Jeremy wrote: > >> >>> Kris has done some excellent benchmarking as usual. Here you can see the >>> improvement in postgres depending on various scheduler debug settings: >>> >>> http://people.freebsd.org/~kris/scaling/pgsql-16cpu.png >> >> The improvement is quite substantial. Congratulations Jeff. > > the drop off after 14 is intersting.. It's contention on various kernel locks, most likely the proc lock. Scheduling algorithms which limit concurrency at contention can improve throughput in these cases but it is to the detriment of workloads which do not suffer the same contention. The ultimate solution will be to improve proc/sleepq/signal locking for 8.0. > >> >