From owner-svn-src-all@FreeBSD.ORG Wed Jun 26 09:10:59 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 32D143B2; Wed, 26 Jun 2013 09:10:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id B335918E3; Wed, 26 Jun 2013 09:10:56 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r5Q9At9w011676; Wed, 26 Jun 2013 13:10:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r5Q9AtQL011675; Wed, 26 Jun 2013 13:10:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 26 Jun 2013 13:10:55 +0400 From: Gleb Smirnoff To: Bruce Evans Subject: Re: svn commit: r252032 - head/sys/amd64/include Message-ID: <20130626091055.GU1214@FreeBSD.org> References: <20130622124832.S2347@besplex.bde.org> <20130622174921.I3112@besplex.bde.org> <20130623073343.GY91021@kib.kiev.ua> <20130623181458.J2256@besplex.bde.org> <20130624170849.GH91021@kib.kiev.ua> <20130625102023.K899@besplex.bde.org> <20130625062039.GJ91021@kib.kiev.ua> <20130625190352.P986@besplex.bde.org> <20130625205826.GM91021@kib.kiev.ua> <20130626092955.B891@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130626092955.B891@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 26 Jun 2013 09:10:59 -0000 Bruce, On Wed, Jun 26, 2013 at 11:42:39AM +1000, Bruce Evans wrote: B> > Anyway, as Gleb said, there is no point in B> > optimizing the i386 kernel. B> B> I said that there is every point in optimizing the i386 kernel. This B> applies even more to other 32-bit arches. Some CPUs are much slower B> than modern x86's. They shouldn't be slowed down more by inefficient B> KPIs. I didn't mean that i386 arch is a relic and should be ignored at all. What I actually meant, is that the problem of performance drop due to cache poisoning and loss of statistics with simple "+=" operation can be observed only at extremely high event rates, with multiple processors involved. The counter(9) is solution for these conditions. Thus we are interested in optimising amd64, not i386. The latter isn't affected neither positively nor negatively with these changes, just because last i386 CPUs can't reach the event rates where need for counter(9) arises. Yes, you can tweak implementation and obtain better results with microbenchmarks, but I bet that any change in counter(9) implementation won't affect packet forwarding rate on any i386. What we claim for i386 (and all other arches) that counter(9) is lossless, and that's all. I second to Konstantin, that we don't have objections in any changes to i386 part of counter, including a daemon, but the changes shouldn't affect amd64. -- Totus tuus, Glebius.