Messages in this thread | | | Date | Mon, 27 Feb 2023 20:45:26 +0700 | From | Ammar Faizi <> | Subject | Re: [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for btrfs |
| |
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@gnuweeb.org> 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
| |