Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: J Louis Kaplan <Louis.Kaplan@arm.com>
To: cel@kernel.org, dai.ngo@oracle.com, jlayton@kernel.org,
	neil@brown.name, okorniev@redhat.com, tom@talpey.com
Cc: anna@kernel.org, jgg@ziepe.ca, leon@kernel.org,
	linux-nfs@vger.kernel.org, linux-rdma@vger.kernel.org,
	trondmy@kernel.org
Subject: Re: [RFC PATCH 0/6] Improve NFS server direct throughput with passthrough enabled
Date: Thu,  8 Oct 2026 23:50:30 +0100	[thread overview]
Message-ID: <20261008225030.643512-1-Louis.Kaplan@arm.com> (raw)
In-Reply-To: <cbc3ff79-4866-4433-a01b-3d5eeab1962b@app.fastmail.com>

> Actually a similar approach has been tried before... And it had to be
> reverted

Thanks for sharing these useful links. They provide important context
that I was not aware of.

I'll have another read through the investigations and commit dates
to better understand the change timeline, but I wanted to share some
contention data I gathered prompted by your feedback.

During development of this patch series, I did notice lock contention
issues. I suspected the unbound workqueue but my analysis was shallow
and I didn't have a good idea how to improve the situation.

After a rebase I noticed a decrease in contention and found your commit
58202c29de936 in the git log which looked likely to be the beneficial
change.

I set up two test branches after reading your feedback. Both apply this
patch series (with minor conflict resolutions) to the older nfsd-testing
commit a39f0ce0c9da2 which reverts `Use contiguous pages for RDMA Read
sink buffers`. `ubwq` also reverts your patch 58202c29de936 whereas
`no-ubwq` does not.

For direct IO on the server and NFS reads in configuration A I mentioned
above (passthrough enabled), here are representative top lines of perf
contention data (spinlocks only).

ubwq (without 58202c29de936)
contended   total wait    max wait   avg wait   caller
   202787    588.67 ms   334.01 us    2.90 us   __rmqueue_pcplist+0x320
   281818    586.91 ms   267.99 us    2.08 us   free_pcppages_bulk+0x48
    88218    100.65 ms     5.57 us    1.14 us   rcu_report_qs_rdp+0x44
     1124     11.07 ms    28.13 us    9.85 us   tick_do_update_jiffies64+0x48
     5773      4.92 ms     3.42 us     851 ns   tmigr_update_events+0x184
     1274      2.38 ms    66.01 us    1.87 us   nfsd4_sequence_done+0x70
     1272      2.36 ms    51.23 us    1.86 us   nfsd4_sequence+0x114
     1074      2.05 ms     5.57 us    1.90 us   acpi_os_wait_semaphore+0x80
     1074      1.68 ms    15.68 us    1.56 us   free_pcppages_bulk+0x48
      739      1.04 ms     4.80 us    1.41 us   __queue_work+0xd4
      424    745.28 us     8.99 us    1.76 us   raw_spin_rq_lock_nested+0x3c
      362    649.74 us    18.78 us    1.79 us   __rmqueue_pcplist+0x320
    ... <truncated>

no-ubwq (with 58202c29de936):
contended   total wait   max wait   avg wait   caller
    68113     82.67 ms    5.92 us    1.21 us   rcu_report_qs_rdp+0x44
     1604      2.41 ms   21.73 us    1.50 us   nfsd4_sequence_done+0x70
     1689      2.31 ms   26.21 us    1.37 us   nfsd4_sequence+0x114
      884      1.66 ms   15.87 us    1.88 us   raw_spin_rq_lock_nested+0x3c
      153      1.21 ms   16.48 us    7.93 us   tick_do_update_jiffies64+0x48
      311    566.99 us   14.43 us    1.82 us   raw_spin_rq_lock_nested+0x3c
      423    459.48 us    2.98 us    1.09 us   force_qs_rnp+0x104
      185    335.12 us   27.14 us    1.81 us   __lwq_dequeue+0x34
       40    288.12 us   20.35 us    7.20 us   free_pcppages_bulk+0x48
      220    285.37 us    3.97 us    1.30 us   __queue_work+0xd4
      284    242.78 us    2.14 us     854 ns   tmigr_update_events+0x184
      153    216.64 us    3.10 us    1.41 us   acpi_os_wait_semaphore+0x80
      164    216.03 us   26.43 us    1.32 us   find_stateid_by_type+0x40
      143    206.07 us   13.66 us    1.44 us   nfsd4_sequence+0x238
       95    118.24 us    2.40 us    1.24 us   dma_pool_alloc+0x50
       85    116.29 us    2.75 us    1.37 us   acpi_os_signal_semaphore+0x88
       86    101.37 us    5.54 us    1.18 us   raw_spin_rq_lock_nested+0x3c
       34     84.18 us    8.45 us    2.47 us   mix_interrupt_randomness+0x104
       72     77.31 us    1.95 us    1.07 us   raw_spin_rq_lock_nested+0x3c
       43     74.94 us    4.29 us    1.74 us   raw_spin_rq_lock_nested+0x3c
       51     72.09 us    3.33 us    1.41 us   acpi_os_wait_semaphore+0x80
       62     67.26 us    1.92 us    1.08 us   dma_pool_free+0x3c
       42     61.66 us    2.46 us    1.47 us   acpi_os_wait_semaphore+0x80
       39     55.87 us    2.94 us    1.43 us   __queue_work+0xd4
       21     50.65 us   15.23 us    2.41 us   raw_spin_rq_lock_nested+0x3c
       35     45.76 us    2.05 us    1.31 us   raw_spin_rq_lock_nested+0x3c
       15     24.16 us    3.93 us    1.61 us   free_pcppages_bulk+0x48
    ... <truncated>

CPU usage was 7% lower in the no-ubwq branch. Throughput remained similar
in both branches for this test.

I'm still digesting the above (and more) data and trying to understand
how all the information fits together, but I wanted to share the above
in the meantime.

      reply	other threads:[~2026-10-08 22:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06  9:00 [RFC PATCH 0/6] Improve NFS server direct throughput with passthrough enabled J Louis Kaplan
2026-10-06  9:00 ` [RFC PATCH 1/6] sunrpc: Add helpers to build bvecs from contiguous pages J Louis Kaplan
2026-10-06 13:49   ` Chuck Lever
2026-10-08 22:44     ` J Louis Kaplan
2026-10-06  9:00 ` [RFC PATCH 2/6] nfsd: Coalesce contiguous pages for direct reads J Louis Kaplan
2026-10-06  9:00 ` [RFC PATCH 3/6] svcrdma: Coalesce contiguous pages when mapping replies J Louis Kaplan
2026-10-06 13:55   ` Chuck Lever
2026-10-08 22:54     ` J Louis Kaplan
2026-10-06  9:00 ` [RFC PATCH 4/6] svcrdma: Coalesce contiguous pages in RDMA Write chunks J Louis Kaplan
2026-10-06  9:00 ` [RFC PATCH 5/6] svcrdma: Coalesce contiguous pages in RDMA Read chunks J Louis Kaplan
2026-10-06  9:00 ` [RFC PATCH 6/6] sunrpc: Allocate svc request pages from large folios J Louis Kaplan
2026-10-06 14:00   ` Chuck Lever
2026-10-08 22:58     ` J Louis Kaplan
2026-10-09 15:28       ` Chuck Lever
2026-10-06 13:47 ` [RFC PATCH 0/6] Improve NFS server direct throughput with passthrough enabled Chuck Lever
2026-10-08 22:50   ` J Louis Kaplan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261008225030.643512-1-Louis.Kaplan@arm.com \
    --to=louis.kaplan@arm.com \
    --cc=anna@kernel.org \
    --cc=cel@kernel.org \
    --cc=dai.ngo@oracle.com \
    --cc=jgg@ziepe.ca \
    --cc=jlayton@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    --cc=trondmy@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox