[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca1e604a-92ba-023b-8896-dcad9413081d@linux.alibaba.com>
Date: Fri, 24 Feb 2023 02:52:54 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-erofs@...ts.ozlabs.org, Chao Yu <chao@...nel.org>,
Yue Hu <huyue2@...lpad.com>,
Jeffle Xu <jefflexu@...ux.alibaba.com>,
Sandeep Dhavale <dhavale@...gle.com>, kernel-team@...roid.com,
LKML <linux-kernel@...r.kernel.org>,
Nathan Huckleberry <nhuck@...gle.com>
Subject: Re: [PATCH v5] erofs: add per-cpu threads for decompression as an
option
Hi Eric,
On 2023/2/24 02:29, Eric Biggers wrote:
> Hi,
>
> On Wed, Feb 08, 2023 at 05:33:22PM +0800, Gao Xiang wrote:
>> From: Sandeep Dhavale <dhavale@...gle.com>
>>
>> Using per-cpu thread pool we can reduce the scheduling latency compared
>> to workqueue implementation. With this patch scheduling latency and
>> variation is reduced as per-cpu threads are high priority kthread_workers.
>>
>> The results were evaluated on arm64 Android devices running 5.10 kernel.
>
> I see that this patch was upstreamed. Meanwhile, commit c25da5b7baf1d
> ("dm verity: stop using WQ_UNBOUND for verify_wq") was also upstreamed.
>
> Why is this more complex solution better than simply removing WQ_UNBOUND?
I do think it's a specific issue on specific arm64 hardwares (assuming
qualcomm, I don't know) since WQ_UNBOUND decompression once worked well
on the hardwares I once used (I meant Hisilicon, and most x86_64 CPUs,
I tested at that time) compared with per-cpu workqueue.
Also RT threads are also matchable with softirq approach. In addition,
many configurations work without dm-verity.
I don't have more time to dig into it for now but it's important to
resolve this problem on some arm64 hardwares first. Also it's an
optional stuff, if the root cause of workqueue issue can be resolved,
we could consider drop it then.
Thsnka,
Gao Xiang
>
> - Eric
Powered by blists - more mailing lists