From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:40454 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751492AbdF1Q6G (ORCPT ); Wed, 28 Jun 2017 12:58:06 -0400 Message-ID: <1498669079.20270.120.camel@redhat.com> Subject: Re: Async direct IO write vs buffered read race From: Rik van Riel To: Jeff Moyer , Jan Kara , Lukas Czerner Cc: linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, esandeen@redhat.com, Christoph Hellwig Date: Wed, 28 Jun 2017 12:57:59 -0400 In-Reply-To: References: <20170622155722.wnkicghc3rkpnvac@localhost.localdomain> <20170623075942.GC25149@quack2.suse.cz> <20170623101621.ggixwdjsnm7k5ch4@localhost.localdomain> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-vUo3JIkGaOeWkqFPzhwy" Mime-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --=-vUo3JIkGaOeWkqFPzhwy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2017-06-26 at 11:11 -0400, Jeff Moyer wrote: > Lukas Czerner writes: >=20 > > > The thing we do is a best effort thing that more or less > > > guarantees that if > > > you do say buffered IO and direct IO after that, it will work > > > reasonably. > > > However if direct and buffered IO can race, bad luck for your > > > data. I don't > > > think we want to sacrifice any performance of AIO DIO (and > > > offloading of > > > direct IO completion to a workqueue so that we can do > > > invalidation costs > > > noticeable mount of performance) for supporting such usecase. > >=20 > > What Jeff proposed would sacrifice performance for the case where > > AIO > > DIO write does race with buffered IO - the situation we agree is > > not ideal > > and should be avoided anyway. For the rest of AIO DIO this should > > have no > > effect right ? If true, I'd say this is a good effort to make sure > > we do > > not have disparity between page cache and disk. >=20 > Exactly.=C2=A0=C2=A0Jan, are you concerned about impacting performance fo= r > mixed > buffered I/O and direct writes?=C2=A0=C2=A0If so, we could look into > restricting > the process context switch further, to just overlapping buffered and > direct I/O (assuming there are no locking issues). >=20 > Alternatively, since we already know this is racy, we don't actually > have to defer I/O completion to process context.=C2=A0=C2=A0We could just > complete > the I/O as we normally would, but also queue up an > invalidate_inode_pages2_range work item.=C2=A0=C2=A0It will be asynchrono= us, > but > this is best effort, anyway. >=20 > As Eric mentioned, the thing that bothers me is that we have invalid > data lingering in the page cache indefinitely. Given that the requirement is that the page cache gets invalidated after IO completion, would it be possible to defer only the page cache invalidation to task context, and handle the rest of the IO completion in interrupt context? --=20 All rights reversed --=-vUo3JIkGaOeWkqFPzhwy 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 v2 iQEcBAABCAAGBQJZU+AXAAoJEM553pKExN6DgA0IAK9F8GzglmqsZ6xhWqj5ABs1 QAMp7SKAQQg1oTYbuGbY78tutJ+LEWi2xnd3Q9FnFm3b1jjCuJZbVq7MscLLSZ9E IlipPN4Wtp0WHlioyCCEOwNiPWZiBW/BWpefKCLY/8M4HaTQ03HHh4+oXvCE62yZ e5BrHCdgBxeqeSkfG9L9atlmrQjyN3U1OInKazdeJHlRco5bVHbpuX9ATIai22VJ gAuAeWircx2buQAE3hHlYIoS0kIguNa4y++ioyHDczKcZnfO8smDTO4hM/+QfRU2 EXzx8J4fcGfzDPg/MvlVzEX7JM8f/nga3DXw63wk8rPpRwIHtHmcFg5owA+9IcE= =V6jv -----END PGP SIGNATURE----- --=-vUo3JIkGaOeWkqFPzhwy--