linux-kernel - Re: [RFC PATCH v1 0/6] Introducing `wq_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Mon, 27 Feb 2023 16:48:03 +0700
From:   Ammar Faizi <ammarfaizi2@...weeb.org>
To:     Hillf Danton <hdanton@...a.com>
Cc:     Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
        David Sterba <dsterba@...e.com>, Tejun Heo <tj@...nel.org>,
        Filipe Manana <fdmanana@...e.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for
 btrfs

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