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-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	Namjae Jeon <namjae.jeon@samsung.com>,
	Amit Sahrawat <a.sahrawat@samsung.com>
Subject: Re: [PATCH 4/4] f2fs: add blk plugging support in f2fs
Date: Tue, 15 Jan 2013 11:40:15 +0900	[thread overview]
Message-ID: <1358217615.8234.35.camel@kjgkr> (raw)
In-Reply-To: <CAKYAXd-f_rLJ5YdtsOX40XiGcNFivPTiXJ5kt03E-AOpuinMMQ@mail.gmail.com>

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

2013-01-14 (월), 20:10 +0900, Namjae Jeon:
> 2013/1/14, Jaegeuk Kim <jaegeuk.kim@samsung.com>:
> > 2013-01-12 (토), 14:42 +0900, Namjae Jeon:
> >> From: Namjae Jeon <namjae.jeon@samsung.com>
> >>
> >> With f2fs having different writepages support for data, node and
> >> metapages.
> >> It will not be covered under the generic blk plug support.
> >
> > Could you show any improvement points with this patch?
> >
> > Currently, there is no reason to use blk plugging, since f2fs itself
> > gathers bios and then submit one big bio.
> >
> > Thanks,
> Hi Jaegeuk,
> 
> There is no performance difference after introducing the block
> plugging in F2FS.

Well, this patch is not a bug fix, but an enhancement patch.
Therefore we need to come up with how exactly the blk plugging support
makes an effect on the performance.

> We introduced this to reduced block lock contention for f2fs also.

> For every BIO request queuing part to the request queue: it needs to
> acquire lock->
> spin_lock_irq(q->queue_lock);
> 
> Even though the F2FS - already is handling the requests part very
> well. But still we can make use of blk_plug to reduce the block lock
> contention.
> 
> When we introduce block plugging to F2FS part - all the requests will
> first be maintained on TASK basis and then pushed to the request
> queue. So, we do not have contention for the “queue lock”.
> 

What I concern is how much block lock contention would be serious.
Let's see the following operational differences.

1. Merging bios prior to grabing "queue lock"
 The f2fs merges consecutive IOs in the file system level before
submitting any bios, which is similar with the back merge by the
plugging mechanism in attempt_plug_merge(). Both of them need to acquire
no queue lock.

2. Merging policy with respect to tasks
 The f2fs merges IOs as much as possible regardless of tasks, while
blk-plugging is conducted on a basis of tasks. As we can understand
there are trade-offs, f2fs tries to maximize the write performance with
well-merged bios. 

As a result, if f2fs produces many consecutive but separated bios in
writepages(), it would be good to use blk-plugging. Since as you said,
f2fs would be able to avoid queue lock contention in the block layer by
merging them.
But, f2fs merges IOs and submit one bio, which means that there are not
much chances to merge bios by attempt_plug_merge().

How do you think?

Thanks,

-- 
Jaegeuk Kim
Samsung

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

  reply	other threads:[~2013-01-15  2:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-12  5:42 [PATCH 4/4] f2fs: add blk plugging support in f2fs Namjae Jeon
2013-01-14  1:50 ` Jaegeuk Kim
2013-01-14 11:10   ` Namjae Jeon
2013-01-15  2:40     ` Jaegeuk Kim [this message]
2013-01-15  7:32       ` Namjae Jeon
2013-01-15  8:02         ` Jaegeuk Kim
2013-01-15  8:11           ` 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=1358217615.8234.35.camel@kjgkr \
    --to=jaegeuk.kim@samsung.com \
    --cc=a.sahrawat@samsung.com \
    --cc=linkinjeon@gmail.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namjae.jeon@samsung.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;
as well as URLs for NNTP newsgroup(s).