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]

Message-ID: <CAKYAXd-f_rLJ5YdtsOX40XiGcNFivPTiXJ5kt03E-AOpuinMMQ@mail.gmail.com>
Date:	Mon, 14 Jan 2013 20:10:01 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	jaegeuk.kim@...sung.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/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.
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/