lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 31 Oct 2008 16:51:44 -0700 (PDT) From: David Miller <davem@...emloft.net> To: dada1@...mosbay.com Cc: zbr@...emap.net, shemminger@...tta.com, ilpo.jarvinen@...sinki.fi, rjw@...k.pl, mingo@...e.hu, s0mbre@...rvice.net.ru, a.p.zijlstra@...llo.nl, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, efault@....de, akpm@...ux-foundation.org Subject: Re: [tbench regression fixes]: digging out smelly deadmen. From: Eric Dumazet <dada1@...mosbay.com> Date: Fri, 31 Oct 2008 22:03:00 +0100 > Evgeniy Polyakov a écrit : > > On Fri, Oct 31, 2008 at 12:57:13PM -0700, Stephen Hemminger (shemminger@...tta.com) wrote: > >> Why bother with last_rx at all on loopback. I have been thinking > >> we should figure out a way to get rid of last_rx all together. It only > >> seems to be used by bonding, and the bonding driver could do the calculation > >> in its receive handling. > > Not related to the regression: bug will be just papered out by this > > changes. Having bonding on loopback is somewhat strange idea, but still > > this kind of changes is an attempt to make a good play in the bad game: > > this loopback-only optimization does not fix the problem. > > Just to be clear, this change was not meant to be committed. > It already was rejected by David some years ago (2005, and 2006) > > http://www.mail-archive.com/netdev@vger.kernel.org/msg07382.html However, I do like Stephen's suggestion that maybe we can get rid of this ->last_rx thing by encapsulating the logic completely in the bonding driver. > If you read my mail, I was *only* saying that tbench results can be sensible to > cache line ping pongs. tbench is a crazy benchmark, and only is a crazy benchmark. > > Optimizing linux for tbench sake would be .... crazy ? Unlike dbench I think tbench is worth cranking up as much as possible. It doesn't have a huge memory working set, it just writes mostly small messages over a TCP socket back and forth, and does a lot of blocking And I think we'd like all of those operating to run as fast as possible. When Tridge first wrote tbench I would see the expected things at the top of the profiles. Things like tcp_ack(), copy to/from user, and perhaps SLAB. Things have changed considerably. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists