From: Damien Le Moal <dlemoal@kernel.org>
To: Kyrylo Biryuk <illofspeed@gmail.com>, dm-devel@lists.linux.dev
Cc: mpatocka@redhat.com, snitzer@kernel.org, agk@redhat.com,
bmarzins@redhat.com, hare@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/3] dm zoned: keep polling for idle reclaim after a reclaim pass
Date: Tue, 13 Oct 2026 14:48:02 +0200 [thread overview]
Message-ID: <9b516b68-de11-479a-abfb-ec11b31fda5f@kernel.org> (raw)
In-Reply-To: <20261013123940.952-4-illofspeed@gmail.com>
On 2026/10/13 14:39, Kyrylo Biryuk wrote:
> dmz_reclaim_work() re-arms its DMZ_IDLE_PERIOD poll only when
> dmz_should_reclaim() returns false at the start of a pass (and, with the
> first patch of this series, when a pass fails with -ENOSPC). After a pass
> it calls dmz_schedule_reclaim(), which queues the work only if reclaim
> is needed right now. When a pass ends while the target is still busy and
> has enough free zones, nothing is queued at all. Once the target goes
> idle, nothing re-evaluates dmz_should_reclaim() until another zone
> allocation, a "reclaim" message or a resume schedules the work, so the
> random or cache zones that filled up under load stay full.
>
> Seen on md RAID5 members on 27 TB host-managed drives: after heavy
> writes the random zones stayed full for hours on idle targets; the
> workaround was a timer sending "dmsetup message <dev> 0 reclaim". With
> this patch the emptied and filled zones were reclaimed within minutes of
> the targets going idle, without the timer.
>
> When reclaim is not needed right now, make dmz_schedule_reclaim() queue
> the idle poll, so the work stays queued after every pass. It uses
> queue_delayed_work(), which leaves already pending work alone, so the
> other callers (zone allocation and the "reclaim" message) neither
> postpone a pending poll nor delay a pending immediate reclaim.
>
> Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
> Assisted-by: LLM
> Signed-off-by: Kyrylo Biryuk <illofspeed@gmail.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
--
Damien Le Moal
Western Digital Research
prev parent reply other threads:[~2026-10-13 12:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 12:39 [PATCH v4 0/3] dm zoned: fix two idle reclaim problems Kyrylo Biryuk
2026-10-13 12:39 ` [PATCH v4 1/3] dm zoned: back off when reclaim finds no destination zone Kyrylo Biryuk
2026-10-13 12:39 ` [PATCH v4 2/3] dm zoned: do not reclaim a random zone into another random zone Kyrylo Biryuk
2026-10-13 12:39 ` [PATCH v4 3/3] dm zoned: keep polling for idle reclaim after a reclaim pass Kyrylo Biryuk
2026-10-13 12:48 ` Damien Le Moal [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b516b68-de11-479a-abfb-ec11b31fda5f@kernel.org \
--to=dlemoal@kernel.org \
--cc=agk@redhat.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=hare@suse.de \
--cc=illofspeed@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.