linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-block@vger.kernel.org
Subject: Re: [PATCH 1/4] f2fs: avoid very large discard command
Date: Thu, 23 Feb 2017 10:41:27 -0800	[thread overview]
Message-ID: <20170223184127.GB2026@jaegeuk.local> (raw)
In-Reply-To: <20170223101627.GA31074@infradead.org>

On 02/23, Christoph Hellwig wrote:
> On Wed, Feb 22, 2017 at 08:28:47PM -0800, Jaegeuk Kim wrote:
> > This patch adds MAX_DISCARD_BLOCKS() to avoid issuing too much large single
> > discard command.
> 
> Needs an explanation in the code on why this number was chosen.

No need to add a trivial comment, since it's the section size which we can
easily translate it.

> In doubt I suspect it should be a quirk in the driver for the device,
> and not something decided by the fs.

The block allocator checks all the issued bios whether any of them contains
the newly allocated address or not. If one large discard command was issued,
it needs to wait for its completion, even if we want to allocate part of its
address space.

In addition, HM-SMR is required to issue discard/reset in a unit of section
size.

Thanks,

> 
> > 
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> >  fs/f2fs/f2fs.h    | 3 ++-
> >  fs/f2fs/segment.c | 3 ++-
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index d076b94530bc..5f3fe97df055 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -133,7 +133,8 @@ enum {
> >  		(SM_I(sbi)->trim_sections * (sbi)->segs_per_sec)
> >  #define BATCHED_TRIM_BLOCKS(sbi)	\
> >  		(BATCHED_TRIM_SEGMENTS(sbi) << (sbi)->log_blocks_per_seg)
> > -
> > +#define MAX_DISCARD_BLOCKS(sbi)						\
> > +		((1 << (sbi)->log_blocks_per_seg) * (sbi)->segs_per_sec)
> >  #define DISCARD_ISSUE_RATE	8
> >  #define DEF_CP_INTERVAL			60	/* 60 secs */
> >  #define DEF_IDLE_INTERVAL		5	/* 5 secs */
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index fe434cd872b4..567019940e9b 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -886,7 +886,8 @@ static void __add_discard_entry(struct f2fs_sb_info *sbi,
> >  	if (!list_empty(head)) {
> >  		last = list_last_entry(head, struct discard_entry, list);
> >  		if (START_BLOCK(sbi, cpc->trim_start) + start ==
> > -						last->blkaddr + last->len) {
> > +				last->blkaddr + last->len &&
> > +				last->len < MAX_DISCARD_BLOCKS(sbi)) {
> >  			last->len += end - start;
> >  			goto done;
> >  		}
> > -- 
> > 2.11.0
> > 
> ---end quoted text---

  reply	other threads:[~2017-02-23 18:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-23  4:28 [PATCH 1/4] f2fs: avoid very large discard command Jaegeuk Kim
2017-02-23  4:28 ` [PATCH 2/4] f2fs: much larger batched trim_fs job Jaegeuk Kim
2017-02-23  4:28 ` [PATCH 3/4] f2fs: wait for discard completion after submission Jaegeuk Kim
2017-02-23  4:28 ` [PATCH 4/4] f2fs: check discard alignment only for SEQWRITE zones Jaegeuk Kim
2017-02-23 10:16 ` [PATCH 1/4] f2fs: avoid very large discard command Christoph Hellwig
2017-02-23 18:41   ` Jaegeuk Kim [this message]
2017-02-27  2:09 ` [f2fs-dev] " Chao Yu

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=20170223184127.GB2026@jaegeuk.local \
    --to=jaegeuk@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).