fuse: give wakeup hints to the scheduler for synchronous requests

When a synchronous FUSE request is sent, the in-kernel client queues it
on fiq->pending and wakes the userspace daemon sleeping in
fuse_dev_do_read()->wait_event_interruptible_exclusive(fiq->waitq, ...).
The client then blocks in request_wait_answer() waiting for the reply,
so the waker is about to go to sleep: this is exactly the pattern that
WF_SYNC is meant to optimise.
As Peter Zijlstra explained in the earlier discussion [1],
WF_SYNC is a hint that the waker is about to sleep and the waker and
wakee share data, so stacking the woken thread on the current CPU
is beneficial for cache locality instead of searching for an idle one.

Add a wake_up_sync() wrapper for task on the synchronous request path.

Performance:

  On an Android big.LITTLE device where the FUSE daemon (MediaProvider)
  runs as a background service on the little cores while foreground
  applications run on the big cores, the synchronous wakeup hint lets
  the scheduler pull the daemon thread onto the big core that is
  issuing the request, where the request data is cache-hot.  Measured
  by qixiaoyu [2] on a 2000-picture zip decompression to /sdcard:

    ------------------------------------------
    | Default   | patched     | Improvement |
    ------------------------------------------
    | 13.0 s    | 7.0 s       | 46%         |
    ------------------------------------------

    Server thread wall duration: 3583 ms -> 1276 ms
    Server runs on big core:       5% -> 79%

  The original 4K-file copy/compress/decompress workload [1] on the
  same kind of device showed a ~28% improvement (13.8s -> 9.9s).

  Note: Miklos reported [2] that on his test box he could not observe
  an actual migration from wake_up_interruptible_sync(); the benefit
  appears to be most visible on asymmetric topologies (big.LITTLE,
  where the daemon normally lives on a little core) and on workloads
  dominated by small synchronous requests.  No regression was
  reported on the symmetric- SMP test setups tried.

The earlier version of this change [1] added a `bool sync` argument
to all three hooks of `struct fuse_iqueue_ops` and threaded it
through virtio_fs as well.  Miklos questioned the interface churn,
and the patch has been stalled since.

Re-work it so the exported interface is left alone.  The hint is
carried in a new FR_SYNC_WAKEUP bit of the existing `fuse_req->flags`
bitfield (an `unsigned long`, so no layout change):

  - __fuse_request_send() sets the flag before fuse_send_one().
  - fuse_dev_queue_req() consumes it with test_and_clear_bit() and
    forwards the result to fuse_dev_wake_and_unlock(), which then
    picks wake_up_sync() or wake_up().
  - The forget, interrupt and resend paths pass `false` explicitly,
    preserving their original wake_up() behaviour.

Only /dev/fuse ever wakes fiq->waitq; virtio_fs and fuse_uring
dispatch through their own transport and never call wake_up(), so
threading `sync` through their ops would just add an unused argument.
test_and_clear_bit() makes the flag a one-shot hint that cannot leak
into a future requeue, and no extra cleanup is needed in
fuse_request_end()/fuse_put_request().

[1] https://lore.kernel.org/lkml/1638780405-38026-1-git-send-email-quic_pragalla@quicinc.com/
[2] https://lore.kernel.org/lkml/20221222093407.GA1141@mi-HP-ProDesk-680-G4-MT/

This work is based on "Pradeep P V K <quic_pragalla@quicinc.com>"  and
"Pavankumar Kondeti <quic_pkondeti@quicinc.com>"

Assisted-by: TRAE:GLM-5.2
Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>

0 files changed, 0 insertions, 0 deletions