From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from moutng.kundenserver.de ([212.227.126.177]) by canuck.infradead.org with esmtp (Exim 4.63 #1 (Red Hat Linux)) id 1HxSF0-0002yM-Gr for linux-mtd@lists.infradead.org; Sun, 10 Jun 2007 14:34:21 -0400 From: Arnd Bergmann To: =?utf-8?q?J=C3=B6rn_Engel?= Subject: Re: [Patch 15/18] fs/logfs/super.c Date: Sun, 10 Jun 2007 20:33:05 +0200 References: <20070603183845.GA8952@lazybastard.org> <200706101827.50948.arnd@arndb.de> <20070610173828.GA32619@lazybastard.org> In-Reply-To: <20070610173828.GA32619@lazybastard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200706102033.11211.arnd@arndb.de> Cc: akpm@osdl.org, David Weinehall , Dongjun Shin , Kyle Moffett , linux-mtd@lists.infradead.org, Pavel Machek , Sam Ravnborg , Ulisses Furquim , CaT , Evgeniy Polyakov , Roland Dreier , Jamie Lokier , Pekka Enberg , Jan Engelhardt , Thomas Gleixner , Bill Davidsen , Albert Cahalan , John Stoffel , linux-kernel@vger.kernel.org, Ondrej Zajicek , linux-fsdevel@vger.kernel.org, David Woodhouse , Willy Tarreau List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sunday 10 June 2007, J=C3=B6rn Engel wrote: > On Sun, 10 June 2007 18:27:49 +0200, Arnd Bergmann wrote: > > On Sunday 03 June 2007, J=C3=B6rn Engel wrote: > > How about using submit_bio here instead of going to the page cache? > > That would avoid doubling all the memory consumption here. >=20 > That may make sense, yes. "May", because there is no simple mapping > between physical data and logical data. In ext3, everything is > block-aligned, usually to 4KiB =3D=3D PAGE_SIZE. So the exact same conte= nt > would exists in two pages. In LogFS, data is compressed and > byte-aligned. A bdev page can contain several full objects that after > uncompression get stored in one page each. Then maybe the submit_bio logic should only be done for the ->write path, not for ->read. The data that gets written out should already be present in the page cache for the files, so there is not much point having again, while you can see the read path as blockdev readahead: When you read a physical block that contains a logical block, it's likely to also contain part of another logical block that is going to be read in the near future. This way, you would also get exclusively clean pages in the block device address_space, which can be easily discarded. Also, maintaining correct ordering between write requests can be done easier if you insert the bios directly, instead of waiting for the lru writeback. Arnd <>< From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757902AbXFJSeg (ORCPT ); Sun, 10 Jun 2007 14:34:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753220AbXFJSe1 (ORCPT ); Sun, 10 Jun 2007 14:34:27 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]:60547 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752637AbXFJSeZ convert rfc822-to-8bit (ORCPT ); Sun, 10 Jun 2007 14:34:25 -0400 From: Arnd Bergmann To: =?utf-8?q?J=C3=B6rn_Engel?= Subject: Re: [Patch 15/18] fs/logfs/super.c Date: Sun, 10 Jun 2007 20:33:05 +0200 User-Agent: KMail/1.9.6 Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, akpm@osdl.org, Sam Ravnborg , John Stoffel , David Woodhouse , Jamie Lokier , Artem Bityutskiy , CaT , Jan Engelhardt , Evgeniy Polyakov , David Weinehall , Willy Tarreau , Kyle Moffett , Dongjun Shin , Pavel Machek , Bill Davidsen , Thomas Gleixner , Albert Cahalan , Pekka Enberg , Roland Dreier , Ondrej Zajicek , Ulisses Furquim References: <20070603183845.GA8952@lazybastard.org> <200706101827.50948.arnd@arndb.de> <20070610173828.GA32619@lazybastard.org> In-Reply-To: <20070610173828.GA32619@lazybastard.org> X-Face: >j"dOR3XO=^3iw?0`(E1wZ/&le9!.ok[JrI=S~VlsF~}"P\+jx.GT@=?utf-8?q?=0A=09-oaEG?=,9Ba>v;3>:kcw#yO5?B:l{(Ln.2)=?utf-8?q?=27=7Dfw07+4-=26=5E=7CScOpE=3F=5D=5EXdv=5B/zWkA7=60=25M!DxZ=0A=09?= =?utf-8?q?8MJ=2EU5?="hi+2yT(k`PF~Zt;tfT,i,JXf=x@eLP{7B:"GyA\=UnN) =?utf-8?q?=26=26qdaA=3A=7D-Y*=7D=3A3YvzV9=0A=09=7E=273a=7E7I=7CWQ=5D?=<50*%U-6Ewmxfzdn/CK_E/ouMU(r?FAQG/ev^JyuX.%(By`" =?utf-8?q?L=5F=0A=09H=3Dbj?=)"y7*XOqz|SS"mrZ$`Q_syCd MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200706102033.11211.arnd@arndb.de> X-Provags-ID: V01U2FsdGVkX1/i/J3ygrv35UKigRBX5AymIq8ZnQ98Riu4MKg K71r01TN8TcTqVYZ6BNl4dLtmyVNQ4An1h4sm9rTzir/vhMAvK pq5Er8TWI3PzVVR1h6Etg== Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sunday 10 June 2007, Jörn Engel wrote: > On Sun, 10 June 2007 18:27:49 +0200, Arnd Bergmann wrote: > > On Sunday 03 June 2007, Jörn Engel wrote: > > How about using submit_bio here instead of going to the page cache? > > That would avoid doubling all the memory consumption here. > > That may make sense, yes. "May", because there is no simple mapping > between physical data and logical data. In ext3, everything is > block-aligned, usually to 4KiB == PAGE_SIZE. So the exact same content > would exists in two pages. In LogFS, data is compressed and > byte-aligned. A bdev page can contain several full objects that after > uncompression get stored in one page each. Then maybe the submit_bio logic should only be done for the ->write path, not for ->read. The data that gets written out should already be present in the page cache for the files, so there is not much point having again, while you can see the read path as blockdev readahead: When you read a physical block that contains a logical block, it's likely to also contain part of another logical block that is going to be read in the near future. This way, you would also get exclusively clean pages in the block device address_space, which can be easily discarded. Also, maintaining correct ordering between write requests can be done easier if you insert the bios directly, instead of waiting for the lru writeback. Arnd <>< From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [Patch 15/18] fs/logfs/super.c Date: Sun, 10 Jun 2007 20:33:05 +0200 Message-ID: <200706102033.11211.arnd@arndb.de> References: <20070603183845.GA8952@lazybastard.org> <200706101827.50948.arnd@arndb.de> <20070610173828.GA32619@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, akpm@osdl.org, Sam Ravnborg , John Stoffel , David Woodhouse , Jamie Lokier , Artem Bityutskiy , CaT , Jan Engelhardt , Evgeniy Polyakov , David Weinehall , Willy Tarreau , Kyle Moffett , Dongjun Shin , Pavel Machek , Bill Davidsen , Thomas Gleixner , Albert Cahalan , Pekka Enberg , Roland Dreier , Ondrej Zajicek , Ulisses Furquim To: =?utf-8?q?J=C3=B6rn_Engel?= Return-path: Received: from moutng.kundenserver.de ([212.227.126.177]:60547 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752637AbXFJSeZ convert rfc822-to-8bit (ORCPT ); Sun, 10 Jun 2007 14:34:25 -0400 In-Reply-To: <20070610173828.GA32619@lazybastard.org> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sunday 10 June 2007, J=C3=B6rn Engel wrote: > On Sun, 10 June 2007 18:27:49 +0200, Arnd Bergmann wrote: > > On Sunday 03 June 2007, J=C3=B6rn Engel wrote: > > How about using submit_bio here instead of going to the page cache? > > That would avoid doubling all the memory consumption here. >=20 > That may make sense, yes. "May", because there is no simple mapping > between physical data and logical data. In ext3, everything is > block-aligned, usually to 4KiB =3D=3D PAGE_SIZE. So the exact same c= ontent > would exists in two pages. In LogFS, data is compressed and > byte-aligned. A bdev page can contain several full objects that afte= r > uncompression get stored in one page each. Then maybe the submit_bio logic should only be done for the ->write path, not for ->read. The data that gets written out should already be present in the page cache for the files, so there is not much point having again, while you can see the read path as blockdev readahead: When you read a physical block that contains a logical block, it's likely to also contain part of another logical block that is going to be read in the near future. This way, you would also get exclusively clean pages in the block device address_space, which can be easily discarded. Also, maintaining correct ordering between write requests can be done easier if you insert the bios directly, instead of waiting for the lru writeback. Arnd <>< - 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