From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754056Ab3HBPkQ (ORCPT ); Fri, 2 Aug 2013 11:40:16 -0400 Received: from relay.parallels.com ([195.214.232.42]:45024 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753695Ab3HBPkO (ORCPT ); Fri, 2 Aug 2013 11:40:14 -0400 Message-ID: <51FBD2DF.50506@parallels.com> Date: Fri, 2 Aug 2013 19:40:15 +0400 From: Maxim Patlasov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Miklos Szeredi CC: , , , , , , , , , , , , , Subject: Re: [PATCH 10/16] fuse: Implement writepages callback References: <20130629172211.20175.70154.stgit@maximpc.sw.ru> <20130629174525.20175.18987.stgit@maximpc.sw.ru> <20130719165037.GA18358@tucsk.piliscsaba.szeredi.hu> In-Reply-To: <20130719165037.GA18358@tucsk.piliscsaba.szeredi.hu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.30.17.2] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 07/19/2013 08:50 PM, Miklos Szeredi пишет: > On Sat, Jun 29, 2013 at 09:45:29PM +0400, Maxim Patlasov wrote: >> From: Pavel Emelyanov >> >> The .writepages one is required to make each writeback request carry more than >> one page on it. The patch enables optimized behaviour unconditionally, >> i.e. mmap-ed writes will benefit from the patch even if fc->writeback_cache=0. > I rewrote this a bit, so we won't have to do the thing in two passes, which > makes it simpler and more robust. Waiting for page writeback here is wrong > anyway, see comment above fuse_page_mkwrite(). BTW we had a race there because > fuse_page_mkwrite() didn't take the page lock. I've also fixed that up and > pushed a series containing these patches up to implementing ->writepages() to > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git writepages > > Passed some trivial testing but more is needed. Thanks a lot for efforts. The approach you implemented looks promising, but it introduces the following assumption: a page cannot become dirty before we have a chance to wait on fuse writeback holding the page locked. This is already true for mmap-ed writes (due to your fixes) and it seems doable for cached writes as well (like we do in fuse_perform_write). But the assumption seems to be broken in case of direct read from local fs (e.g. ext4) to a memory region mmap-ed to a file on fuse fs. See how dio_bio_submit() marks pages dirty by bio_set_pages_dirty(). I can't see any solution for this use-case. Do you? Thanks, Maxim > > I'll get to the rest of the patches next week. > > Thanks, > Miklos > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Patlasov Subject: Re: [PATCH 10/16] fuse: Implement writepages callback Date: Fri, 2 Aug 2013 19:40:15 +0400 Message-ID: <51FBD2DF.50506@parallels.com> References: <20130629172211.20175.70154.stgit@maximpc.sw.ru> <20130629174525.20175.18987.stgit@maximpc.sw.ru> <20130719165037.GA18358@tucsk.piliscsaba.szeredi.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: , , , , , , , , , , , , , To: Miklos Szeredi Return-path: In-Reply-To: <20130719165037.GA18358@tucsk.piliscsaba.szeredi.hu> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org 07/19/2013 08:50 PM, Miklos Szeredi =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Sat, Jun 29, 2013 at 09:45:29PM +0400, Maxim Patlasov wrote: >> From: Pavel Emelyanov >> >> The .writepages one is required to make each writeback request carry m= ore than >> one page on it. The patch enables optimized behaviour unconditionally, >> i.e. mmap-ed writes will benefit from the patch even if fc->writeback_= cache=3D0. > I rewrote this a bit, so we won't have to do the thing in two passes, w= hich > makes it simpler and more robust. Waiting for page writeback here is w= rong > anyway, see comment above fuse_page_mkwrite(). BTW we had a race there= because > fuse_page_mkwrite() didn't take the page lock. I've also fixed that up= and > pushed a series containing these patches up to implementing ->writepage= s() to > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git writ= epages > > Passed some trivial testing but more is needed. Thanks a lot for efforts. The approach you implemented looks promising,=20 but it introduces the following assumption: a page cannot become dirty=20 before we have a chance to wait on fuse writeback holding the page=20 locked. This is already true for mmap-ed writes (due to your fixes) and=20 it seems doable for cached writes as well (like we do in=20 fuse_perform_write). But the assumption seems to be broken in case of=20 direct read from local fs (e.g. ext4) to a memory region mmap-ed to a=20 file on fuse fs. See how dio_bio_submit() marks pages dirty by=20 bio_set_pages_dirty(). I can't see any solution for this use-case. Do you= ? Thanks, Maxim > > I'll get to the rest of the patches next week. > > Thanks, > Miklos > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx153.postini.com [74.125.245.153]) by kanga.kvack.org (Postfix) with SMTP id 7E84F6B0032 for ; Fri, 2 Aug 2013 11:40:07 -0400 (EDT) Message-ID: <51FBD2DF.50506@parallels.com> Date: Fri, 2 Aug 2013 19:40:15 +0400 From: Maxim Patlasov MIME-Version: 1.0 Subject: Re: [PATCH 10/16] fuse: Implement writepages callback References: <20130629172211.20175.70154.stgit@maximpc.sw.ru> <20130629174525.20175.18987.stgit@maximpc.sw.ru> <20130719165037.GA18358@tucsk.piliscsaba.szeredi.hu> In-Reply-To: <20130719165037.GA18358@tucsk.piliscsaba.szeredi.hu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Miklos Szeredi Cc: riel@redhat.com, dev@parallels.com, xemul@parallels.com, fuse-devel@lists.sourceforge.net, bfoster@redhat.com, linux-kernel@vger.kernel.org, jbottomley@parallels.com, linux-mm@kvack.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org, fengguang.wu@intel.com, devel@openvz.org, mgorman@suse.de 07/19/2013 08:50 PM, Miklos Szeredi D?D,N?DuN?: > On Sat, Jun 29, 2013 at 09:45:29PM +0400, Maxim Patlasov wrote: >> From: Pavel Emelyanov >> >> The .writepages one is required to make each writeback request carry more than >> one page on it. The patch enables optimized behaviour unconditionally, >> i.e. mmap-ed writes will benefit from the patch even if fc->writeback_cache=0. > I rewrote this a bit, so we won't have to do the thing in two passes, which > makes it simpler and more robust. Waiting for page writeback here is wrong > anyway, see comment above fuse_page_mkwrite(). BTW we had a race there because > fuse_page_mkwrite() didn't take the page lock. I've also fixed that up and > pushed a series containing these patches up to implementing ->writepages() to > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git writepages > > Passed some trivial testing but more is needed. Thanks a lot for efforts. The approach you implemented looks promising, but it introduces the following assumption: a page cannot become dirty before we have a chance to wait on fuse writeback holding the page locked. This is already true for mmap-ed writes (due to your fixes) and it seems doable for cached writes as well (like we do in fuse_perform_write). But the assumption seems to be broken in case of direct read from local fs (e.g. ext4) to a memory region mmap-ed to a file on fuse fs. See how dio_bio_submit() marks pages dirty by bio_set_pages_dirty(). I can't see any solution for this use-case. Do you? Thanks, Maxim > > I'll get to the rest of the patches next week. > > Thanks, > Miklos > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org