linux-kernel - Re: [PATCH 4/4] f2fs: add blk plugging support in f2fs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Jan 2013 11:40:15 +0900
From:	Jaegeuk Kim <jaegeuk.kim@...sung.com>
To:	Namjae Jeon <linkinjeon@...il.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net,
	Namjae Jeon <namjae.jeon@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>
Subject: Re: [PATCH 4/4] f2fs: add blk plugging support in f2fs

2013-01-14 (월), 20:10 +0900, Namjae Jeon:
> 2013/1/14, Jaegeuk Kim <jaegeuk.kim@...sung.com>:
> > 2013-01-12 (토), 14:42 +0900, Namjae Jeon:
> >> From: Namjae Jeon <namjae.jeon@...sung.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

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)