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: Thu, 1 Sep 2022 21:16:34 -0400 From: Kent Overstreet <kent.overstreet@...ux.dev> To: Roman Gushchin <roman.gushchin@...ux.dev> Cc: Yosry Ahmed <yosryahmed@...gle.com>, Michal Hocko <mhocko@...e.com>, Mel Gorman <mgorman@...e.de>, Peter Zijlstra <peterz@...radead.org>, Suren Baghdasaryan <surenb@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Vlastimil Babka <vbabka@...e.cz>, Johannes Weiner <hannes@...xchg.org>, dave@...olabs.net, Matthew Wilcox <willy@...radead.org>, liam.howlett@...cle.com, void@...ifault.com, juri.lelli@...hat.com, ldufour@...ux.ibm.com, Peter Xu <peterx@...hat.com>, David Hildenbrand <david@...hat.com>, axboe@...nel.dk, mcgrof@...nel.org, masahiroy@...nel.org, nathan@...nel.org, changbin.du@...el.com, ytcoode@...il.com, vincent.guittot@...aro.org, dietmar.eggemann@....com, Steven Rostedt <rostedt@...dmis.org>, bsegall@...gle.com, bristot@...hat.com, vschneid@...hat.com, Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, Joonsoo Kim <iamjoonsoo.kim@....com>, 42.hyeyoo@...il.com, glider@...gle.com, elver@...gle.com, dvyukov@...gle.com, Shakeel Butt <shakeelb@...gle.com>, Muchun Song <songmuchun@...edance.com>, arnd@...db.de, jbaron@...mai.com, David Rientjes <rientjes@...gle.com>, minchan@...gle.com, kaleshsingh@...gle.com, kernel-team@...roid.com, Linux-MM <linux-mm@...ck.org>, iommu@...ts.linux.dev, kasan-dev@...glegroups.com, io-uring@...r.kernel.org, linux-arch@...r.kernel.org, xen-devel@...ts.xenproject.org, linux-bcache@...r.kernel.org, linux-modules@...r.kernel.org, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH 00/30] Code tagging framework and applications On Thu, Sep 01, 2022 at 06:04:46PM -0700, Roman Gushchin wrote: > On Thu, Sep 01, 2022 at 08:17:47PM -0400, Kent Overstreet wrote: > > On Thu, Sep 01, 2022 at 03:53:57PM -0700, Roman Gushchin wrote: > > > I'd suggest to run something like iperf on a fast hardware. And maybe some > > > io_uring stuff too. These are two places which were historically most sensitive > > > to the (kernel) memory accounting speed. > > > > I'm getting wildly inconsistent results with iperf. > > > > io_uring-echo-server and rust_echo_bench gets me: > > Benchmarking: 127.0.0.1:12345 > > 50 clients, running 512 bytes, 60 sec. > > > > Without alloc tagging: 120547 request/sec > > With: 116748 request/sec > > > > https://github.com/frevib/io_uring-echo-server > > https://github.com/haraldh/rust_echo_bench > > > > How's that look to you? Close enough? :) > > Yes, this looks good (a bit too good). Eh, I was hoping for better :) > I'm not that familiar with io_uring, Jens and Pavel should have a better idea > what and how to run (I know they've workarounded the kernel memory accounting > because of the performance in the past, this is why I suspect it might be an > issue here as well). > > This is a recent optimization on the networking side: > https://lore.kernel.org/linux-mm/20220825000506.239406-1-shakeelb@google.com/ > > Maybe you can try to repeat this experiment. I'd be more interested in a synthetic benchmark, if you know of any.
Powered by blists - more mailing lists