On Mon, 27 Feb 2023 20:45:26 +0700 Ammar Faizi <ammarfaizi2@xxxxxxxxx> wrote: > 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. The end user should not be expected to do that. (At least that is my opinion as an end user :) The worst part, in times when Btrfs has no current work to do, it means the user apps are hard-capped to 4 cores for no good reason, and the other 4 are idling. Even with a split like 6/2, this is still looks like giving up on the achievements of multi-tasking operating systems and falling back to some antique state with fixed separation. > 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. I really hope there can be some other approach. Such as some adjustment to kworker processing so that it's not as aggressive in starving userspace. There are no possibility to run kernel task at a lower priority, right? But if no other way, maybe an option like that is good to have for the moment. -- With respect, Roman
