From owner-freebsd-current@FreeBSD.ORG Sun Oct 14 09:47:25 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11E86857; Sun, 14 Oct 2012 09:47:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ED8858FC17; Sun, 14 Oct 2012 09:47:23 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28653; Sun, 14 Oct 2012 12:47:22 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TNKn4-000CbC-GJ; Sun, 14 Oct 2012 12:47:22 +0300 Message-ID: <507A8A29.4070601@FreeBSD.org> Date: Sun, 14 Oct 2012 12:47:21 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 CC: freebsd-current@FreeBSD.org Subject: Re: new DragonFly-3.2 scheduler and PostgreSQL comparision with FreeBSD 9.1-RC1 References: <1350153522261-5751733.post@n5.nabble.com> <5079DCCE.4020901@FreeBSD.org> In-Reply-To: <5079DCCE.4020901@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 09:47:25 -0000 on 14/10/2012 00:27 Pedro Giffuni said the following: > Actually ... > > On 10/13/2012 13:38, Jakub Lach wrote: >> I'm not at all up to date with DragonFly, so does anybody know >> what did they change so spectacularly between 3.0/3.2? >> > Their explanation of the changes is here: > > http://www.shiningsilence.com/dbsdlog/2012/09/19/10403.html >From the article: (3) It will detect process block/wakeup events which e.g. tie two processes together, and will try to move the process pairs closer to each other using that information. For example, if you have many postgres clients and servers on a large server, enough to load down all cores, the client and server pairs will be localized to the same socket, thus making use of chip caches to facilitate communications between the two processes. This sounds like a nice heuristic. Currently our code unintentionally does the opposite quite often. -- Andriy Gapon