From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755841Ab3AOCkZ (ORCPT ); Mon, 14 Jan 2013 21:40:25 -0500 Received: from mailout2.samsung.com ([203.254.224.25]:12812 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752734Ab3AOCkX (ORCPT ); Mon, 14 Jan 2013 21:40:23 -0500 X-AuditID: cbfee61b-b7f616d00000319b-f4-50f4c1955ec2 Message-id: <1358217615.8234.35.camel@kjgkr> Subject: Re: [PATCH 4/4] f2fs: add blk plugging support in f2fs From: Jaegeuk Kim Reply-to: jaegeuk.kim@samsung.com To: Namjae Jeon Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Namjae Jeon , Amit Sahrawat Date: Tue, 15 Jan 2013 11:40:15 +0900 In-reply-to: References: <1357969323-9396-1-git-send-email-linkinjeon@gmail.com> <1358128249.23942.6.camel@kjgkr> Organization: samsung Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-H7Q5/HDp6t1ZJIn0NM4o" X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-version: 1.0 DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42I5/e+Zoe7Ug18CDFbu47HYs/cki8XlXXPY HJg8Pm+SC2CM4rJJSc3JLEst0rdL4MronDyLrWCCbMXFTbENjIcluhg5OSQETCSOfr7HAmGL SVy4t54NxBYSWMYo8WeiCEzN/J5rjF2MXEDxRYwST958YIEoes0oceZdMojNK6AjsejcLPYu Rg4OYQF7iXW3qkBMNgFtic37DSCqFSXe7r/LChIWEVCTmPAsFWQis8AuRoljR5eATWQRUJVY 9nQn2BROgWCJDf9zIbauZZR4v24pWA2/gKjEydZPjCA2s0CVxIP+14wQZypJ7G7vZIe4RlDi x+R7UDMFJL5NPsQCMlNCQFZi0wFmkJkSArfYJR5cvsYO0SspcXDFDZYJjOKzkIydhWQURFxT onX7b3YIW1ti2cLXzBC2rcS6de+hamwkNl1dwAhhy0tsfzuHeQEj+ypG0dSC5ILipPRcI73i xNzi0rx0veT83E2MkGiU3sG4qsHiEKMAB6MSD+9N3S8BQqyJZcWVuYcYVYDmPNqw+gKjFEte fl6qkgjvtT6gNG9KYmVValF+fFFpTmrxIcZkoE8nMkuJJucDE0heSbyhsbGJmYmpibmlqbkp acJK4ryMp54ECAmkJ5akZqemFqQWwWxh4uCUamDkrDwZvjpZXkXZgeEle6XsF49OEZuvH5zt pkpxOU00L+zxsd6sq/bV0oUp/LoU03ZLUcGzxc9l3Vc6yof7WS57qvfwp9GBm9O475mkfY3N 81/AdC/8/LxDQd3Lcs9ads8IWHvo5OOI0EL1q5r7pDyzzojvfmIhZWT2t09if3xt5Im03jqL HiWW4oxEQy3mouJEAHL5XgcWAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsVy+t9jAd2pB78EGGy7z2axZ+9JFovLu+aw OTB5fN4kF8AY1cBok5GamJJapJCal5yfkpmXbqvkHRzvHG9qZmCoa2hpYa6kkJeYm2qr5OIT oOuWmQM0WkmhLDGnFCgUkFhcrKRvh2lCaIibrgVMY4Sub0gQXI+RARpIWMeY0Tl5FlvBBNmK i5tiGxgPS3QxcnJICJhIzO+5xghhi0lcuLeerYuRi0NIYBGjxJM3H1hAEkICrxklzrxLBrF5 BXQkFp2bxd7FyMEhLGAvse5WFYjJJqAtsXm/AUS1osTb/XdZQcIiAmoSE56lgkxkFtjFKHHs 6BKwiSwCqhLLnu4Em8IpECyx4X8uxNa1jBLv1y0Fq+EXEJU42foJ7DRmgSqJB/2voc5Uktjd 3skOcY2gxI/J91gmMArOQlI2C0kKIq4p0br9NzuErS2xbOFrZgjbVmLduvdQNTYSm64uYISw 5SW2v53DvICRfRWjaGpBckFxUnqukV5xYm5xaV66XnJ+7iZGcLQ/k97BuKrB4hCjAAejEg/v Td0vAUKsiWXFlbmHGFWA5jzasPoCoxRLXn5eqpII77U+oDRvSmJlVWpRfnxRaU5q8SHGZGBo TGSWEk3OByaovJJ4Q2MTMyNLIzMLIxNzc9KElcR5GU89CRASSE8sSc1OTS1ILYLZwsTBKdXA mB/5b91ez5PSnToSWmF3/+z+e8N774xoVdPUat31hn/ary2xOxC6mInLxfiAzb+8pa2XJPde eZmQF2kp3C2iFzj3T/W1dY+i2U/aqLw/vVYjVDuxxULrFvPb3hDWhDeVSf6m76z6jJZGsz5r 3v3+mcQG9bO6pq4R4ufYM6wUoi49scpS07ymxFKckWioxVxUnAgAquEMvkYDAAA= X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-H7Q5/HDp6t1ZJIn0NM4o Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2013-01-14 (=EC=9B=94), 20:10 +0900, Namjae Jeon: > 2013/1/14, Jaegeuk Kim : > > 2013-01-12 (=ED=86=A0), 14:42 +0900, Namjae Jeon: > >> From: Namjae Jeon > >> > >> 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, >=20 > 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); >=20 > 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. >=20 > 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 =E2=80=9Cqueue lock=E2=80=9D= . >=20 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.=20 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, --=20 Jaegeuk Kim Samsung --=-H7Q5/HDp6t1ZJIn0NM4o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJQ9MGPAAoJEEAUqH6CSFDS7fMQAJGNfHFqu+JEF/DmSKf6cx01 g6o4DLG/rOHfF4wx0FNxpizHtjLK8JfLkxNpkFdMJvt2tSpM7VuU6PzWfPQe6Rm3 +ubaoTXMnP1ZtOiOkTMEymOy3xocGCgAuytiD4rSdyg7qJ/s5qLOT/Jl91/5T1mU CoC9Y0Kcv1Ww68uc+eus1yEKuX8V4HgZGZPLCEh4Td07uMz18OLSssYLOjLXrG4S C757VWCD6YGBMuSmN8iNfLY+Yf+t/WyP0YnBE/Mn8oXNUxEwfyQX3Uhw5/BU6RzO /R2dIQhWWtsBRwk8OCcgFRzkPkADJ5DSadVxd4VgHHaEwTWF/NIWHYAp2kDKsj4U /eJYryPagQ3tU3gE9MJH8oZgHhpjeOuQ4BM0PNiXST4P7bsWnxJjqUffGtcykeZ+ B3MFqJf8owCxSzDhycfbJRLyzb5o1BzfdpKJRT0hNRdAqSt4tv7/vZmoZLyzpiu1 1QYol2hrITUWasNlHpoiNmX0jVmjbGou3AXkpGRBZp6kcJp0Q3SC+c3Ptd8OqtgX 04eS/nKz+l7Qj2H99qOdxwP8cdC0HLDVnjXGSX5neSIJDOCwI5/bQKNvpz0pkdbg hlk/VdS8+BBOt4gsDdJulx/w8AwTfuH+8/meB5YT9vM63KI4P2c1oHzdui+HFDs2 gZfQuSVhf11LAH6yqivF =GsK/ -----END PGP SIGNATURE----- --=-H7Q5/HDp6t1ZJIn0NM4o--