Re: [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for btrfs

[Ammar Faizi]

On Mon, Feb 27, 2023 at 11:04:38AM +0800, Hillf Danton wrote:
> Are the sensitive user tasks likely also preempted by the kblockd_workqueue[1]
> for instance?
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/blk-mq.c#n2258

I didn't see any kblockd_workqueue influence.

>From my observation, the issue is btrfs-specific, especially for write
operations with high-level compression. It does not happen with ext4.

(Well, it doesn't compress the data with ext4, so no doubt it's lighter).

Seeing from htop, several kthreads consume CPU time:

   - kworker btrfs-dealloc

   - kworker btrfs-endio-write

   - kworker btrfs-worker-high

   - kworker btrfs-compressed-write

   - ... there are more, but all of them are btrfs workqueues.

They perform heavy work when there is an intensive writing operation.
However, for the read operation, there is no visible issue.

Increasing vm.dirty_ratio and vm.background_dirty_ratio, plus using

   -o commit=N (mount option)

where N is a large number helps a lot. But it slows my entire system
down when it starts syncing the dirty write to the disk. It freezes the
UI for 2 to 3 seconds and causes audio lag.

Isolating btrfs workqueues and UI tasks in a different set of CPUs, as
proposed in this series, solves the issue.

-- 
Ammar Faizi