svn commit: r252032 - head/sys/amd64/include

[Gleb Smirnoff]

  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.