[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c7e108a6-c788-d3d9-346c-9db134ae9ae2@huaweicloud.com>
Date: Tue, 27 May 2025 16:03:45 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Hannes Reinecke <hare@...e.de>, Yu Kuai <yukuai1@...weicloud.com>,
hch@....de, xni@...hat.com, colyli@...nel.org, song@...nel.org
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-raid@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com,
johnny.chenyi@...wei.com, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH 11/23] md/md-bitmap: make method bitmap_ops->daemon_work
optional
Hi,
在 2025/05/27 14:19, Hannes Reinecke 写道:
> On 5/24/25 08:13, Yu Kuai wrote:
>> From: Yu Kuai <yukuai3@...wei.com>
>>
>> daemon_work() will be called by daemon thread, on the one hand, daemon
>> thread doesn't have strict wake-up time; on the other hand, too much
>> work are put to daemon thread, like handle sync IO, handle failed
>> or specail normal IO, handle recovery, and so on. Hence daemon thread
>> may be too busy to clear dirty bits in time.
>>
>> Make bitmap_ops->daemon_work() optional and following patches will use
>> separate async work to clear dirty bits for the new bitmap.
>>
> Why not move it to a workqueue in general?
> The above argument is valid even for the current implementation, no?
Yes, and however, I'll prefer not to touch current implementaion :(
This is trivial comparing to other flaws like global spinlock.
Thanks,
Kuai
>
> Cheers,
>
> Hannes
Powered by blists - more mailing lists