On 2/27/23 6:46 PM, Qu Wenruo wrote:
On 2023/2/27 19:02, Filipe Manana wrote:
On Sun, Feb 26, 2023 at 4:31 PM Ammar Faizi <ammarfaizi2@xxxxxxxxxxx> wrote:
Figure (the CPU usage when `wq_cpu_set` is used VS when it is not):
https://gist.githubusercontent.com/ammarfaizi2/a10f8073e58d1712c1ed49af83ae4ad1/raw/a4f7cbc4eb163db792a669d570ff542495e8c704/wq_cpu_set.png
I haven't read the patchset.
It's great that it reduces CPU usage. But does it also provide
other performance benefits, like lower latency or higher throughput
for some workloads? Or using less CPU also affects negatively in
those other aspects?
Based on my testing, it gives lower latency for a browser app playing
a YouTube video.
Without this proposed option, high-level compression on a btrfs
storage is a real noise to user space apps. It periodically freezes
the UI for 2 to 3 seconds and causes audio lag; it mostly happens when
it starts writing the dirty write to the disk.
It's reasonably easy to reproduce by making a large dirty write and
invoking a "sync" command.
Side note: Pin user apps to CPUs a,b,c,d and btrfs workquques to CPUs
w,x,y,z.
So far it looks like to just set CPU masks for each workqueue.
Thus if it's reducing CPU usage, it also takes longer time to finish
the workload (compression,csum calculation etc).
Yes, that's correct.
I see this as a good mount option for btrfs because the btrfs-workload
in question is CPU bound, specifically for the writing operation.
While it may degrade the btrfs workload because we limit the number of
usable CPUs, there is a condition where users don't prioritize writing
to disk.
Let's say:
I want to run a smooth app with video. I also want to have high-level
compression for my btrfs storage. But I don't want the compression and
checksum work to bother my video; here, I give you CPU x,y,z for the
btrfs work. And here I give you CPU a,b,c,d,e,f for the video work.
I have a similar case on a torrent seeder server where high-level
compression is expected. And I believe there are more cases where this
option is advantageous.
Thank you all for the comments,
--
Ammar Faizi
