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: ma...@freebsd.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ------------------------------------------------------------------------ _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
