[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/30] Code tagging framework and applications
- To: Roman Gushchin <roman.gushchin@xxxxxxxxx>, Kent Overstreet <kent.overstreet@xxxxxxxxx>
- From: Jens Axboe <axboe@xxxxxxxxx>
- Date: Fri, 2 Sep 2022 06:02:12 -0600
- Cc: Yosry Ahmed <yosryahmed@xxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, Mel Gorman <mgorman@xxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Suren Baghdasaryan <surenb@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Vlastimil Babka <vbabka@xxxxxxx>, Johannes Weiner <hannes@xxxxxxxxxxx>, dave@xxxxxxxxxxxx, Matthew Wilcox <willy@xxxxxxxxxxxxx>, liam.howlett@xxxxxxxxxx, void@xxxxxxxxxxxxx, juri.lelli@xxxxxxxxxx, ldufour@xxxxxxxxxxxxx, Peter Xu <peterx@xxxxxxxxxx>, David Hildenbrand <david@xxxxxxxxxx>, mcgrof@xxxxxxxxxx, masahiroy@xxxxxxxxxx, nathan@xxxxxxxxxx, changbin.du@xxxxxxxxx, ytcoode@xxxxxxxxx, vincent.guittot@xxxxxxxxxx, dietmar.eggemann@xxxxxxx, Steven Rostedt <rostedt@xxxxxxxxxxx>, bsegall@xxxxxxxxxx, bristot@xxxxxxxxxx, vschneid@xxxxxxxxxx, Christoph Lameter <cl@xxxxxxxxx>, Pekka Enberg <penberg@xxxxxxxxxx>, Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>, 42.hyeyoo@xxxxxxxxx, glider@xxxxxxxxxx, elver@xxxxxxxxxx, dvyukov@xxxxxxxxxx, Shakeel Butt <shakeelb@xxxxxxxxxx>, Muchun Song <songmuchun@xxxxxxxxxxxxx>, arnd@xxxxxxxx, jbaron@xxxxxxxxxx, David Rientjes <rientjes@xxxxxxxxxx>, minchan@xxxxxxxxxx, kaleshsingh@xxxxxxxxxx, kernel-team@xxxxxxxxxxx, Linux-MM <linux-mm@xxxxxxxxx>, iommu@xxxxxxxxxxxxxxx, kasan-dev@xxxxxxxxxxxxxxxx, io-uring@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-bcache@xxxxxxxxxxxxxxx, linux-modules@xxxxxxxxxxxxxxx, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
- Delivery-date: Fri, 02 Sep 2022 12:02:26 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 9/1/22 7:04 PM, 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).
>
> 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).
io_uring isn't alloc+free intensive on a per request basis anymore, it
would not be a good benchmark if the goal is to check for regressions in
that area.
--
Jens Axboe
|