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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 15 Aug 2014 10:59:24 -0700 From: Eric Dumazet <eric.dumazet@...il.com> To: Alexander Duyck <alexander.h.duyck@...el.com> Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org Subject: Re: Performance regression on kernels 3.10 and newer On Fri, 2014-08-15 at 10:15 -0700, Alexander Duyck wrote: > I realize most of my data is anecdotal as I only have the ixgbe/igb > adapters and netperf to work with. This is one of the reasons why I > keep asking if someone can tell me what the use case is for this where > it performs well. From what I can tell it might have had some value > back in the day before the introduction of things such as RPS/RFS where > some of the socket processing would be offloaded to other CPUs for a > single queue device, but even that use case is now deprecated since > RPS/RFS are there and function better than this. What I am basically > looking for is a way to weight the gain versus the penalties to > determine if this code is even viable anymore. > > In the meantime I think I will put together a patch to default > tcp_low_latency to 1 for net and stable, and if we cannot find a good > reason for keeping it then I can submit a patch to net-next that will > strip it out since I don't see any benefit to having this code. prequeue is useful on low end hosts, because it allows an application to delay ACK packets if it is slow. You get a nicer TCP behavior, because its more tied to scheduling glitches. Especially if TCP windows are not autotuned. I guess some embedded platforms benefit from this. I would keep it the way it is, because modern high performance applications do not trigger prequeue anyway. It is trivial to add into netperf a poll() before recvmsg() to avoid the prequeue, or start your benchmarks with appropriate sysctl. It is certainly not a 'stable' candidate change, it has been there for years. Note that we have include/linux/percpu-refcount.h now, we might autodetect some dst are heavily used by different cpus and switch to a percpu refcount. -- 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