From owner-freebsd-arch@FreeBSD.ORG Wed Feb 25 21:50:13 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C6CC82F for ; Wed, 25 Feb 2015 21:50:13 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14605E2C for ; Wed, 25 Feb 2015 21:50:13 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 24AB1B9AD; Wed, 25 Feb 2015 16:50:12 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: locks and kernel randomness... Date: Wed, 25 Feb 2015 15:20:52 -0500 Message-ID: <1774232.7ZAkabLA24@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150225085659.GA74514@kib.kiev.ua> References: <54ED87E9.8030706@astrodoggroup.com> <20150225085659.GA74514@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Feb 2015 16:50:12 -0500 (EST) Cc: Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 21:50:13 -0000 On Wednesday, February 25, 2015 10:56:59 AM Konstantin Belousov wrote: > The cost of the proposed patch, of course, is not the several > thousands of instructions in the rebalance. The problem with it is the > introduction of the new spinlock, which will be used in many places > after the introduction. The cost of the new and often used spinlock is > the increase of both interrupt latency and interrupt handler jitter and > cpu switch jitter. > > So neither buildworld timing, nor network throughput are adequate > to estimate the change. It is system unresponsivness and loss of > the realtime behaviour up to some degree. > > I thought that it was obvious, at least after spinlocks were mentioned, > but apparently it is not, since proposals to measure the patch effect > by benchmarking buildworld or passing the traffic are made. +1 The only thing I will add is that in general this makes the system more fragile and complex as well. Please just stay with a regular mutex and change the scheduler to not use random() (which seems to be in progress?). I'm not sure why we needed the extra 40 messages in this thread after that was effectively said the first time. -- John Baldwin