LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Chao Yu <chao2.yu@samsung.com>
To: "'Jaegeuk Kim'" <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: RE: [PATCH 5/5] f2fs: introduce a batched trim
Date: Fri, 30 Jan 2015 13:13:43 +0800	[thread overview]
Message-ID: <006701d03c4b$a62ec0c0$f28c4240$@samsung.com> (raw)
In-Reply-To: <20150129214117.GB17521@jaegeuk-mac02>

Hi Jaegeuk,

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> Sent: Friday, January 30, 2015 5:41 AM
> To: Chao Yu
> Cc: linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org;
> linux-f2fs-devel@lists.sourceforge.net
> Subject: Re: [PATCH 5/5] f2fs: introduce a batched trim
> 
> Hi Chao,
> 
> On Thu, Jan 29, 2015 at 08:38:30PM +0800, Chao Yu wrote:
> > Hi Jaegeuk,
> >
> > > -----Original Message-----
> > > From: linux-fsdevel-owner@vger.kernel.org [mailto:linux-fsdevel-owner@vger.kernel.org] On
> > > Behalf Of Jaegeuk Kim
> > > Sent: Wednesday, January 28, 2015 7:32 AM
> > > To: linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org;
> > > linux-f2fs-devel@lists.sourceforge.net
> > > Cc: Jaegeuk Kim
> > > Subject: [PATCH 5/5] f2fs: introduce a batched trim
> > >
> > > This patch introduces a batched trimming feature, which submits split discard
> > > commands.
> >
> > I didn't get it, why we should split discard commands. :(
> >
> > Does smaller discarding for flash shows better performance or effect or safety?
> > Can you please explain more about this patch?
> 
> This is to avoid long latency due to huge trim commands.
> If fstrim was triggered ranging from 0 to the end of device, we should lock
> all the checkpoint-related mutexes, resulting in very long latency.

Ah.. thanks for your explanation, how about adding above description into commit
log?

> 
> Thanks,
> 
> >
> > Thanks,
> >
> > >
> > > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > > ---
> > >  fs/f2fs/f2fs.h    |  1 +
> > >  fs/f2fs/segment.c | 15 ++++++++++-----
> > >  2 files changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > index c0b83d6..ec4d16b 100644
> > > --- a/fs/f2fs/f2fs.h
> > > +++ b/fs/f2fs/f2fs.h
> > > @@ -104,6 +104,7 @@ enum {
> > >  	CP_DISCARD,
> > >  };
> > >
> > > +#define BATCHED_TRIM_SEGMENTS	10

Our macro here shows one batched trim discard 10 segments, but actually we
discard 11 segments each time in f2fs_trim_fs, how about making them consistent?

One other point is that, I guess gc in FTL will be triggered each time after
discard command was issued, but if our basic size of one batched trim is not
multiple of gc unit size in FTL, efficiency of gc in FTL will be lower.

Now that f2fs has nature advantage that we can align section size to gc unit
size in FTL. Why not trying to op flash with section size as much as possible?

So how about use this:

#define BATCHED_TRIM_SECTIONS_SHIFT	4

our trim size: section size << BATCHED_TRIM_SECTIONS_SHIFT

Thanks,

> > >  struct cp_control {
> > >  	int reason;
> > >  	__u64 trim_start;
> > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > > index 31c4e57..6c9c784 100644
> > > --- a/fs/f2fs/segment.c
> > > +++ b/fs/f2fs/segment.c
> > > @@ -1066,14 +1066,19 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct fstrim_range
> *range)
> > >  	end_segno = (end >= MAX_BLKADDR(sbi)) ? MAIN_SEGS(sbi) - 1 :
> > >  						GET_SEGNO(sbi, end);
> > >  	cpc.reason = CP_DISCARD;
> > > -	cpc.trim_start = start_segno;
> > > -	cpc.trim_end = end_segno;
> > >  	cpc.trim_minlen = range->minlen >> sbi->log_blocksize;
> > >
> > >  	/* do checkpoint to issue discard commands safely */
> > > -	mutex_lock(&sbi->gc_mutex);
> > > -	write_checkpoint(sbi, &cpc);
> > > -	mutex_unlock(&sbi->gc_mutex);
> > > +	for (; start_segno <= end_segno;
> > > +				start_segno += BATCHED_TRIM_SEGMENTS + 1) {
> > > +		cpc.trim_start = start_segno;
> > > +		cpc.trim_end = min_t(unsigned int,
> > > +				start_segno + BATCHED_TRIM_SEGMENTS, end_segno);
> > > +
> > > +		mutex_lock(&sbi->gc_mutex);
> > > +		write_checkpoint(sbi, &cpc);
> > > +		mutex_unlock(&sbi->gc_mutex);
> > > +	}
> > >  out:
> > >  	range->len = cpc.trimmed << sbi->log_blocksize;
> > >  	return 0;
> > > --
> > > 2.1.1
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2015-01-30  5:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-27 23:31 [PATCH 1/5] f2fs: fix not to drop mount options when retrying fill_super Jaegeuk Kim
2015-01-27 23:31 ` [PATCH 2/5] f2fs: support norecovery mount option Jaegeuk Kim
2015-01-29 11:52   ` Chao Yu
2015-01-29 18:27     ` Jaegeuk Kim
2015-01-29 18:31       ` [f2fs-dev] [PATCH 2/5 v2] " Jaegeuk Kim
2015-01-30  5:11         ` Chao Yu
2015-01-30  5:10       ` [PATCH 2/5] " Chao Yu
2015-01-27 23:31 ` [PATCH 3/5] f2fs: avoid write_checkpoint if f2fs is mounted readonly Jaegeuk Kim
2015-01-29 11:55   ` Chao Yu
2015-01-27 23:31 ` [PATCH 4/5] f2fs: should fail mount when trying to recover data on read-only dev Jaegeuk Kim
2015-01-29 12:16   ` Chao Yu
2015-01-29 21:39     ` Jaegeuk Kim
2015-01-30  5:12       ` Chao Yu
2015-01-30  5:15   ` Chao Yu
2015-01-27 23:31 ` [PATCH 5/5] f2fs: introduce a batched trim Jaegeuk Kim
2015-01-29 12:38   ` Chao Yu
2015-01-29 21:41     ` Jaegeuk Kim
2015-01-30  5:13       ` Chao Yu [this message]
2015-02-02 23:29         ` [PATCH 5/5 v2] " Jaegeuk Kim
2015-02-03  2:48           ` [f2fs-dev] " Changman Lee
2015-02-03 20:10             ` [f2fs-dev] [PATCH 5/5 v3] " Jaegeuk Kim
2015-02-05  9:30               ` Chao Yu
2015-02-06  6:18                 ` [f2fs-dev] [PATCH 5/5 v4] " Jaegeuk Kim
2015-02-06  8:20                   ` Chao Yu
2015-02-07 15:57                   ` Leon Romanovsky
2015-02-09  7:04                     ` Jaegeuk Kim
2015-01-29 11:24 ` [PATCH 1/5] f2fs: fix not to drop mount options when retrying fill_super Chao Yu
2015-01-29 18:21   ` [PATCH 1/5 v2] " Jaegeuk Kim
2015-01-30  5:02     ` 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='006701d03c4b$a62ec0c0$f28c4240$@samsung.com' \
    --to=chao2.yu@samsung.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='RE: [PATCH 5/5] f2fs: introduce a batched trim' \
    /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

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).