linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
To: Namjae Jeon <linkinjeon@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs: avoid issuing small bios due to several dirty node pages
Date: Fri, 18 Jan 2013 17:25:52 +0900	[thread overview]
Message-ID: <1358497552.8234.113.camel@kjgkr> (raw)
In-Reply-To: <CAKYAXd9vGy2sCSWCA_HU2LX7hk86astBVH3gMcZQx=AFy8bnkg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3085 bytes --]

2013-01-18 (금), 16:58 +0900, Namjae Jeon:
> 2013/1/18, Jaegeuk Kim <jaegeuk.kim@samsung.com>:
> > If some small bios of dirty node pages are supposed to be issued during the
> > sequential data writes, there-in well-produced consecutive data bios are
> > able
> > to be split by the small node bios, resulting in performance degradation.
> > So, let's collect a number of dirty node pages until reaching a threshold.
> > And, by default, I set the threshold as 2MB, a segment size.
> >
> > This improves sequential write performance on i5, 512GB SSD (830 w/ SATA2)
> > as
> > follows.
> > Before: 231 MB/s -> After: 255 MB/s
> >
> > Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
> > ---
> >  fs/f2fs/node.c | 17 +++++++++++------
> >  1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index f177c01..9bda63c 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1124,6 +1124,12 @@ static int f2fs_write_node_page(struct page *page,
> >  	return 0;
> >  }
> >
> > +/*
> > + * It is very important to gather dirty pages and write at once, so that we
> > can
> > + * submit a big bio without interfering other data writes.
> > + * Be default, 512 pages (2MB), a segment size, is quite reasonable.
> > + */
> > +#define COLLECT_DIRTY_NODES	512
> Hi Jaeguek.
> It is just my opinion.
> One of f2fs advantages is that user can set segment size to fit own device.
> For future, Is it not good to use segment size set by user(from
> superblock) instead of fixed size ?

At this moment, it's very hard to change the segment size due to many
hardcoded data structures such as SSA, bitmaps, etc.
Instead, I proposed something like section and zone which are based on
segment.
But, somebody will be able to do later. :)

> 
> Thanks.
> 
> >  static int f2fs_write_node_pages(struct address_space *mapping,
> >  			    struct writeback_control *wbc)
> >  {
> > @@ -1131,17 +1137,16 @@ static int f2fs_write_node_pages(struct
> > address_space *mapping,
> >  	struct block_device *bdev = sbi->sb->s_bdev;
> >  	long nr_to_write = wbc->nr_to_write;
> >
> > -	if (wbc->for_kupdate)
> > -		return 0;
> > -
> > -	if (get_pages(sbi, F2FS_DIRTY_NODES) == 0)
> > -		return 0;
> > -
> > +	/* First check balancing cached NAT entries */
> >  	if (try_to_free_nats(sbi, NAT_ENTRY_PER_BLOCK)) {
> >  		write_checkpoint(sbi, false, false);
> >  		return 0;
> >  	}
> >
> > +	/* collect a number of dirty node pages and write together */
> > +	if (get_pages(sbi, F2FS_DIRTY_NODES) < COLLECT_DIRTY_NODES)
> > +		return 0;
> > +
> >  	/* if mounting is failed, skip writing node pages */
> >  	wbc->nr_to_write = bio_get_nr_vecs(bdev);
> >  	sync_node_pages(sbi, 0, wbc);
> > --
> > 1.8.0.1.250.gb7973fb
> >
> > --
> > 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
> >

-- 
Jaegeuk Kim
Samsung

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-01-18  8:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-18  6:29 [PATCH] f2fs: avoid issuing small bios due to several dirty node pages Jaegeuk Kim
2013-01-18  7:58 ` Namjae Jeon
2013-01-18  8:25   ` Jaegeuk Kim [this message]
2013-01-18  8:57     ` Namjae Jeon
2013-01-18  9:28       ` Jaegeuk Kim
2013-01-18  9:37         ` Namjae Jeon

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=1358497552.8234.113.camel@kjgkr \
    --to=jaegeuk.kim@samsung.com \
    --cc=linkinjeon@gmail.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@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).