From owner-freebsd-current@FreeBSD.ORG Sun Oct 14 10:11:47 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 979BF4B0; Sun, 14 Oct 2012 10:11:47 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id CBFF18FC0C; Sun, 14 Oct 2012 10:11:46 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so3435963lag.13 for ; Sun, 14 Oct 2012 03:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Weuuj3YOdhf4xK+Q9mAk4RbI/W4hclAwH5AfKU26i/E=; b=X2jv5lR9GFQQi3DCyLx62TRdK4ZnzyoREQr0U+XqPZzmfmAo5fGie1XV0tytZbIIMu EsfA/kHlaVoOj/F9X3a2d2OX5ABrvs4ebD3gjsf7XGpgCoELMBwkE7AnYu0lwxt0zTFi cFnh4qM2ammjyStMpBXzDst/699rvURDc6qYO/a1WJxLvYtq6mMoUEYtC8Z4hnlkzmWg DYA+5l5XQjGV6JfnozSGTZhr9+nZWH/aW9HP77TekVu0HG6JVRngHmLeb9Hu7wrcWLg8 ZkgrtTzk6DR0+2A5g7ND+ly1j8O88zrS+JngmZnxa2FlQb+0PLkdNFkomJDxJPGH+H2r 7YlA== Received: by 10.112.28.98 with SMTP id a2mr3156669lbh.110.1350209505129; Sun, 14 Oct 2012 03:11:45 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id fp7sm3532612lab.4.2012.10.14.03.11.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Oct 2012 03:11:44 -0700 (PDT) Sender: Alexander Motin Message-ID: <507A8FDD.4040703@FreeBSD.org> Date: Sun, 14 Oct 2012 13:11:41 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andriy Gapon 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> <507A8A29.4070601@FreeBSD.org> In-Reply-To: <507A8A29.4070601@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org 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 10:11:47 -0000 On 14.10.2012 12:47, Andriy Gapon wrote: > 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. Yes, that is true. Present ULE code puts too much attention to the cache/socket load balance and affinity to previous run places. That way is quite simple and straightforward. More sophisticated way would be to have some kind of thresholds (for example, in number of context switches per second) where caller thread cache affinity becomes more important then callee thread's previous cache affinity. But I guess it can be quite application-specific. In mentioned case of PostgreSQL I guess there could be cases when cache affinity between server processes is more important then affinity between servers and clients. -- Alexander Motin