[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac1feea8-325f-4b78-b82d-38930643513a@suse.de>
Date: Tue, 27 May 2025 10:55:30 +0200
From: Hannes Reinecke <hare@...e.de>
To: 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
On 5/27/25 10:03, Yu Kuai wrote:
> 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.
>
Fair enough.
You can add:
Reviewed-by: Hannes Reinecke <hare@...e.de>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@...e.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
Powered by blists - more mailing lists