Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Jun 2013 13:13:37 +0400 (MSK)
From:      Dmitry Morozovsky <marck@rinet.ru>
To:        Gleb Smirnoff <glebius@freebsd.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au>
Subject:   Re: svn commit: r252032 - head/sys/amd64/include
Message-ID:  <alpine.BSF.2.00.1306261313020.1846@woozle.rinet.ru>
In-Reply-To: <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> <20130626091055.GU1214@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Jun 2013, Gleb Smirnoff wrote:

> 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.

Ah, apparently this mostly answers the question I've just asked ;)

-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1306261313020.1846>