From owner-svn-src-all@FreeBSD.ORG Thu Apr 2 15:38:11 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 558CA65B; Thu, 2 Apr 2015 15:38:11 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 D43F26D7; Thu, 2 Apr 2015 15:38:10 +0000 (UTC) Received: by wixm2 with SMTP id m2so58364689wix.0; Thu, 02 Apr 2015 08:38:09 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=1MXf1x2wgxdd7DNjBWM0B7w9l+sFJmRpb2qoXwlb8es=; b=sxsLRXpkY3XDY1dl+nnDoeauNSR90khWpIYOyiAZ9l4LI+28MIFEAMVcoP37pBswfn FKXCtNuwzc+MI63TYv+FDgqY4c7VzeYm4QxVz/V4DhVJFQtbI+QbQoIwtKZvZ4kerYoE BzbFeHSyrdifOdeK6Auht52Pe2g3uOBixs9WRfkrLbRMx7pxmp258oP2iRjdGMYKuAaA FfznHHerj5I6Ukpp2aHdmJ/7VsJCl7EhKFvwID+EL63mF6hMVSNZh4ejmAdQ6wKQOKjJ iX9W+bY8nqTP6JpVbnAohYFEmt1M4IcZlTeyGY/fCaOuhcoz9rlm5O1VhM25QkN7V92g FedQ== X-Received: by 10.180.88.65 with SMTP id be1mr25134305wib.50.1427989089283; Thu, 02 Apr 2015 08:38:09 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id l3sm3500955wiv.18.2015.04.02.08.38.07 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 08:38:08 -0700 (PDT) Date: Thu, 2 Apr 2015 17:38:05 +0200 From: Mateusz Guzik To: Gleb Smirnoff Subject: Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf Message-ID: <20150402153805.GD549@dft-labs.eu> References: <201504012226.t31MQedN044443@svn.freebsd.org> <1427929676.82583.103.camel@freebsd.org> <20150402123522.GC64665@FreeBSD.org> <20150402133751.GA549@dft-labs.eu> <20150402134217.GG64665@FreeBSD.org> <20150402135157.GB549@dft-labs.eu> <1427983109.82583.115.camel@freebsd.org> <20150402142318.GC549@dft-labs.eu> <20150402143420.GI64665@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150402143420.GI64665@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ian Lepore X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:38:11 -0000 On Thu, Apr 02, 2015 at 05:34:20PM +0300, Gleb Smirnoff wrote: > On Thu, Apr 02, 2015 at 04:23:18PM +0200, Mateusz Guzik wrote: > M> Well, a thread migrating to another cpu is the standard thing everyone > M> sees. > > How often do you see it right in a particular window of 2 or > 3 instructions? > > If you carefully read the thread I referred to, you would notice that > on many arches, save amd64 and i386, all systems stats are prone > to mangling the stats due to migration within PCPU_INC. Look here: > > grep '^#define PCPU_ADD' sys/*/include/pcpu.h > > Do we have reports on not precise enough statistics, yet? How many non-x86 installations with multiple cpus and high traffic are out there? Also note that stats should be roughly equally distributed amongst CPUs which do the work, so an occasional mismatch is likely to go unnoticed. Would be nice to get this fixed at some point though. > > M> I don't feel that strongly about changing the code. If it stays as it > M> is, it definitely needs the comment I mentioned explaining why migration > M> is fine. > > I just added the comment. > Thanks! > M> If the code was to be changed a machdep counter_u64_fetchadd seems like > M> the only course of action. > > If we have more places in kernel, where such API is required, I would do > it. Alas, seems like not possible to make it without critical section, > even on amd64. Note that counter_u64_add() on amd64 is critical-less. > Yeah, but that should be cheap. Worst case on amd64 it could be microoptimised with removal of func call and inline critnest manipulation with compiler barrier. Afair Ian said that on arm they could hack around it nicer with atomics, don't remember atm what's the holdup (if any). tl;dr this should be doable without technical problems and does not have to affect counter_u64_add. -- Mateusz Guzik