Date: Wed, 26 Jun 2013 13:10:55 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Konstantin Belousov <kostikbel@gmail.com>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r252032 - head/sys/amd64/include Message-ID: <20130626091055.GU1214@FreeBSD.org> In-Reply-To: <20130626092955.B891@besplex.bde.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130626091055.GU1214>