From owner-freebsd-current@freebsd.org Sun Jul 31 20:36:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23050BA85A9 for ; Sun, 31 Jul 2016 20:36:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8FB91CFA; Sun, 31 Jul 2016 20:36:17 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id o80so217783823wme.1; Sun, 31 Jul 2016 13:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WQzI2hAoTF7M0FSMP5P7hA+im197Z7KTxL6MnJMtCEM=; b=fZfDVTAKaxDjQuwtyZIWQN2OzsBwBjXUM/+k7/zqOaYw6IkCm0HN00xlf6BckYqk41 GSR8qdI2k6X6QNIxmXtxpTu0a7H3zfR7ZCcyy9t3y21+uGBHQ/FxkHZ88WY188MrpW7/ uwoaVsphprO4jUIdvChVpRMStd30lHN7mFE7m4xMCoMx94AhoVpKcWNzL/pnkgC4q5fl yDOKd2qXz3GmuK3IiKxtgn2Ad2Wxfxa428GVBnFTHkpLk1ra/B0TdFNeiI5Onvpn4HZ+ tzLRLdzW7e6oN8pUEoTrRMV7VrMNZYMXLKnkAI00N+wkm64k4zimV+bu7VCCb1tdGd8s hrJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=WQzI2hAoTF7M0FSMP5P7hA+im197Z7KTxL6MnJMtCEM=; b=dtJL4kCP2rbNOSGiU7hZxtSBHXM7YhKes8g4tUwMIUPX8PAmLwpBhNMVbqoA3eaPZ1 +qCUch8hg8VaN3C5gmb3l6vQhLBfN/pznHHzfiUzH/mg9u1LVcfVoedS8prZJf3VTTgF wjRwlJDiX2DDGXp6F8Izi7sDep/E7TEM/u5LDQXGdt+t16zfExpyyj33SRPN1vt/TAUo v2Wv0ScCC20sujSZb1Q0P5NkMiMsjfAGJUShHX8TMWFN9hyLi5vki9Q1BQ1c2h60/j0I afE+HAySOL+tZdb0BlFJlg9xAZP4xTCX2uTE95rntLoQJv1d5Jv6JK4ll0ahutK0mBZP kELQ== X-Gm-Message-State: AEkoouusge0NSpWeDlYV7F6jdb9uX6oJd+JFcUmHBZkmbPXLGu84qolfD8AzsOdvwC+kvQ== X-Received: by 10.194.248.198 with SMTP id yo6mr20989267wjc.66.1469997375237; Sun, 31 Jul 2016 13:36:15 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id x203sm13602761wmg.0.2016.07.31.13.36.14 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 31 Jul 2016 13:36:14 -0700 (PDT) Date: Sun, 31 Jul 2016 22:36:12 +0200 From: Mateusz Guzik To: Adrian Chadd Cc: John Baldwin , freebsd-current , Konstantin Belousov Subject: Re: [PATCH] randomized delay in locking primitives, take 2 Message-ID: <20160731203612.GH9408@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Adrian Chadd , John Baldwin , freebsd-current , Konstantin Belousov References: <20160731095706.GB9408@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 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, 31 Jul 2016 20:36:18 -0000 On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote: > Hi, > > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are > any performance degredations on lower count CPUs? > I did not test on machines which physically that few cpus, but I did test the impact on microbenchmark with 2 and 4 threads on the 80-way machine. There was no difference. For this iteration of the patch, given limited time I tried to be very conservative as to not intoduce additional latency. In fact I would argue the patch is undertuned (as in, it can do better in certain workloads). That said, I think it is safe to use. > Also, yeah, the MOD operator in each loop could get spendy on older > CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to > achieve much the same autotuning with pow2 operations instead of > divide/mod? > The % operation acts a randomizer. It is optional and I'm happy to ifdef it based on the architecture. It does seem to be useful at least on amd64. As a side note, exponential backoff is not used to keep things smaller (see above). It is definitely subject to change later. -- Mateusz Guzik