From: David Sterba <dsterba@suse.cz>
To: Luca Stefani <luca.stefani.ge1@gmail.com>
Cc: dsterba@suse.cz, Qu Wenruo <quwenruo.btrfs@gmx.com>,
Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] btrfs: Split remaining space to discard in chunks
Date: Mon, 2 Sep 2024 22:23:23 +0200 [thread overview]
Message-ID: <20240902202323.GC26776@twin.jikos.cz> (raw)
In-Reply-To: <4bef0c7b-df8b-41dc-9fe1-022cc4937def@gmail.com>
On Mon, Sep 02, 2024 at 10:17:37PM +0200, Luca Stefani wrote:
> > sector_t nr_sects, gfp_t gfp_mask, struct bio **biop)
> > {
> > struct bio *bio;
> >
> > while ((bio = blk_alloc_discard_bio(bdev, §or, &nr_sects,
> > gfp_mask)))
> > *biop = bio_chain_and_submit(*biop, bio);
> > return 0;
> > }
> >
> > This is basically just a loop, chopping the input range as needed. The
> > btrfs code does effectively the same, there's only the superblock,
> > progress accounting and error handling done.
> >
> > As the maximum size of a single discard request depends on a device we
> > don't need to artificially limit it because this would require more IO
> > requests and can be slower.
>
> Thanks for taking a look, this change was prompted after I've been
> seeing issues due to the discard kthread blocking an userspace process
> causing device not to suspend.
> https://lore.kernel.org/lkml/20240822164908.4957-1-luca.stefani.ge1@gmail.com/
> is the proposed solution, but Qu mentioned that there is another place
> where it could happen that I didn't cover, and I think what I change
> here (unless it's the wrong place) allows me to add the similar
> `btrfs_trim_interrupted` checks to stop.
>
> Please let me know if that makes sense to you, if that's the case I
> guess it would make sense to send the 2 patches together?
Yeah for inserting the cancellation points it would make sense to do the
chunking. I'd suggest to do the same logic like blk_alloc_discard_bio()
and use the block device discard request limit and not a fixed constant.
prev parent reply other threads:[~2024-09-02 20:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-02 11:43 Luca Stefani
2024-09-02 20:11 ` David Sterba
2024-09-02 20:17 ` Luca Stefani
2024-09-02 20:23 ` David Sterba [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=20240902202323.GC26776@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.stefani.ge1@gmail.com \
--cc=quwenruo.btrfs@gmx.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
all inboxes | Powered by JetHome®