linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Namjae Jeon <linkinjeon@gmail.com>
To: jaegeuk.kim@samsung.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: Mon, 14 Jan 2013 20:10:01 +0900	[thread overview]
Message-ID: <CAKYAXd-f_rLJ5YdtsOX40XiGcNFivPTiXJ5kt03E-AOpuinMMQ@mail.gmail.com> (raw)
In-Reply-To: <1358128249.23942.6.camel@kjgkr>

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

If we consider the normal data write path: initial block plug is
already taken care by generic write_pages(for f2fs readpages block
plug is already taken care by default path of:
read_pages()->mpage_readpages())),
but we can optimize this write path also as we shared the in patch.
Similarly, we introduced block plug for the node_page and meta_pages.

Please share your opinion on this.

Thanks!
>
> --
> Jaegeuk Kim
> Samsung
>
--
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:[~2013-01-14 11:10 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 [this message]
2013-01-15  2:40     ` Jaegeuk Kim
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=CAKYAXd-f_rLJ5YdtsOX40XiGcNFivPTiXJ5kt03E-AOpuinMMQ@mail.gmail.com \
    --to=linkinjeon@gmail.com \
    --cc=a.sahrawat@samsung.com \
    --cc=jaegeuk.kim@samsung.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).