From: Hillf Danton <hdanton@sina.com>
To: Sergei Shtepa <sergei.shtepa@veeam.com>
Cc: axboe@kernel.dk, corbet@lwn.net, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 17/21] block, blksnap: snapshot image block device
Date: Sun, 1 Jan 2023 15:18:13 +0800 [thread overview]
Message-ID: <20230101071813.3329-1-hdanton@sina.com> (raw)
In-Reply-To: <20221209142331.26395-18-sergei.shtepa@veeam.com>
On 9 Dec 2022 15:23:27 +0100 Sergei Shtepa <sergei.shtepa@veeam.com>
> Provides the operation of block devices of snapshot images. Read and
> write operations are redirected to the regions of difference blocks for
> block device (struct diff_area).
>
> Signed-off-by: Sergei Shtepa <sergei.shtepa@veeam.com>
> ---
Thanks for your patchset.
> +static int snapimage_kthread_worker_fn(void *param)
> +{
> + struct snapimage *snapimage = param;
> + struct bio *bio;
> + int ret = 0;
> +
> + while (!kthread_should_stop()) {
> + bio = get_bio_from_queue(snapimage);
> + if (!bio) {
> + schedule_timeout_interruptible(HZ / 100);
> + continue;
> + }
Given the wake_up_process() below, s$HZ / 100$HZ * 1000$ to avoid
unnecessary wakeups [1].
And because of no signal handling added, use schedule_timeout_idle() instead.
[1] https://lore.kernel.org/lkml/20210419085027.761150-2-elver@google.com/
> +
> + snapimage_process_bio(snapimage, bio);
> + }
> +
> + while ((bio = get_bio_from_queue(snapimage)))
> + snapimage_process_bio(snapimage, bio);
> +
> + return ret;
> +}
> +
> +static void snapimage_submit_bio(struct bio *bio)
> +{
> + struct snapimage *snapimage = bio->bi_bdev->bd_disk->private_data;
> + gfp_t gfp = GFP_NOIO;
> +
> + if (bio->bi_opf & REQ_NOWAIT)
> + gfp |= GFP_NOWAIT;
> + if (snapimage->is_ready) {
> + spin_lock(&snapimage->queue_lock);
> + bio_list_add(&snapimage->queue, bio);
> + spin_unlock(&snapimage->queue_lock);
> +
> + wake_up_process(snapimage->worker);
> + } else
> + bio_io_error(bio);
> +}
next parent reply other threads:[~2023-01-01 7:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20221209142331.26395-1-sergei.shtepa@veeam.com>
[not found] ` <20221209142331.26395-18-sergei.shtepa@veeam.com>
2023-01-01 7:18 ` Hillf Danton [this message]
2023-01-02 9:44 ` Sergei Shtepa
[not found] ` <20221209142331.26395-19-sergei.shtepa@veeam.com>
2023-01-01 11:05 ` [PATCH v2 18/21] block, blksnap: snapshot Hillf Danton
2023-01-02 9:58 ` Sergei Shtepa
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=20230101071813.3329-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sergei.shtepa@veeam.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox