lkml.org 
[lkml]   [2024]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHSET wq/for-6.8] workqueue: Implement system-wide max_active for unbound workqueues
    Hello,

    On Thu, Jan 11, 2024 at 02:49:21PM -1000, Tejun Heo wrote:
    > On Fri, Jan 05, 2024 at 02:44:08AM +0000, Naohiro Aota wrote:
    > > Thank you for the series. I applied the patches on btrfs's development tree
    > > below, and ran the benchmark.
    > >
    > > https://gitlab.com/kdave/btrfs-devel.git misc-next
    > >
    > > - misc-next, numa=off (baseline)
    > > WRITE: bw=1117MiB/s (1171MB/s), 1117MiB/s-1117MiB/s (1171MB/s-1171MB/s), io=332GiB (356GB), run=304322-304322msec
    > > - misc-next + wq patches, numa=off
    > > WRITE: bw=1866MiB/s (1957MB/s), 1866MiB/s-1866MiB/s (1957MB/s-1957MB/s), io=684GiB (735GB), run=375472-375472msec
    > >
    > > So, the patches surely improved the performance. However, as show below, it
    > > is still lower than reverting previous workqueue patches. The reverting is
    > > done by reverse applying output of "git diff 4cbfd3de737b
    > > kernel/workqueue.c kernel/workqueue_internal.h include/linux/workqueue*
    > > init/main.c"
    > >
    > > - misc-next + wq reverted, numa=off
    > > WRITE: bw=2472MiB/s (2592MB/s), 2472MiB/s-2472MiB/s (2592MB/s-2592MB/s), io=732GiB (786GB), run=303257-303257msec
    >
    > Can you describe the test setup in detail? What kind of machine is it? What
    > do you mean by `numa=off`? Can you report tools/workqueue/wq_dump.py output?

    So, I fixed the possible ordering bug that Lai noticed and dropped the last
    patch (more on this in the reply to that path) and did some benchmarking
    with fio and dm-crypt and at least in that testing the new code seems to
    perform just as well as before. The only variable seems to be what
    max_active is used for the workqueue in question.

    For dm-crypt, kcryptd workqueue uses num_online_cpus(). Depending on how the
    value is interpreted, it may not provide high enough concurrency as some
    workers wait for IOs and show slightly slower performance but that's easily
    fixed by bumping max_active value so that there's some buffer, which is the
    right way to configure it anyway.

    It'd be great if you can share more details on the benchmarks you're
    running, so that we can rule out similar issues.

    Thanks.

    --
    tejun

    \
     
     \ /
      Last update: 2024-01-13 01:17    [W:3.859 / U:0.296 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site