From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53499C35FF3 for ; Fri, 21 Mar 2025 04:56:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B427280003; Fri, 21 Mar 2025 00:56:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13E85280001; Fri, 21 Mar 2025 00:56:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F204E280003; Fri, 21 Mar 2025 00:56:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D1CBD280001 for ; Fri, 21 Mar 2025 00:56:49 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5D5E158615 for ; Fri, 21 Mar 2025 04:56:51 +0000 (UTC) X-FDA: 83244348222.29.74CC69A Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf10.hostedemail.com (Postfix) with ESMTP id 74B5EC000C for ; Fri, 21 Mar 2025 04:56:49 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=mit.edu; spf=pass (imf10.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742533009; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XBzAoLAQsFVvnrEspWFoaz9zuPBazxAJhzsq0I8+7BE=; b=ClMMNQM/tmamlAU/3dcso1oirzR7b9m2yKTGGJCpKlEyGjykpGRTq/p2NxBsjqH59PiJiH BhLnZjs2HdTe0DcRWU780u9Y6TN4aGatB2eImDu+u7CbYBG58m65csSsSt+vhE6b8GOdqP Mowrp/FdfcM1Hg5EVdkMukKM/FXXmQA= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=mit.edu; spf=pass (imf10.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742533009; a=rsa-sha256; cv=none; b=sQTNo4Tji66K0Cp8TDRQqQQT9wUQGzgH4PVLYQj3Jwq1j1m4cRX+nyPOHKl/Ah1mMX6DXA CvLVEsM9PUEScXNpVB8PLsl7G7y+rbfIVqAEkANBA5DYiLR7SbCDhYnAUNGGrsfLaW9WTw 4/ep5Y5qLkS9a+8sPpa6OuzBZuj6BsE= Received: from trampoline.thunk.org (pool-173-48-82-222.bstnma.fios.verizon.net [173.48.82.222]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 52L4u4WI017316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Mar 2025 00:56:04 -0400 Received: by trampoline.thunk.org (Postfix, from userid 15806) id 131D02E010B; Fri, 21 Mar 2025 00:56:04 -0400 (EDT) Date: Fri, 21 Mar 2025 00:56:04 -0400 From: "Theodore Ts'o" To: "Darrick J. Wong" Cc: Ritesh Harjani , Luis Chamberlain , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, lsf-pc@lists.linux-foundation.org, david@fromorbit.com, leon@kernel.org, hch@lst.de, kbusch@kernel.org, sagi@grimberg.me, axboe@kernel.dk, joro@8bytes.org, brauner@kernel.org, hare@suse.de, willy@infradead.org, john.g.garry@oracle.com, p.raghav@samsung.com, gost.dev@samsung.com, da.gomez@samsung.com Subject: Re: [LSF/MM/BPF TOPIC] breaking the 512 KiB IO boundary on x86_64 Message-ID: <20250321045604.GA1161423@mit.edu> References: <87o6xvsfp7.fsf@gmail.com> <20250320213034.GG2803730@frogsfrogsfrogs> <87jz8jrv0q.fsf@gmail.com> <20250321030526.GW89034@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250321030526.GW89034@frogsfrogsfrogs> X-Rspamd-Server: rspam01 X-Stat-Signature: gaboud197gnkfw3ksd8o7hebq4njbsns X-Rspam-User: X-Rspamd-Queue-Id: 74B5EC000C X-HE-Tag: 1742533009-452348 X-HE-Meta: U2FsdGVkX1+Iph8ClJKC4s9jJrUU2UyffWx420jQksElBRdA7cMdZkeNwOudRCu6rCb/jpztbpaeL1EMz/31wSVaa7fBc66q0D2pA8dEGGLSIip5ZGtjseWoXsY9jOWnoIQwtZ/Tn7oXh3f9nnwt0XKZinIO50tpFZt7WoBl5QqxUQaganLn6rZ/hw6Evu2m6KM/MNaSzMrcl7WI1aNaGpBgoK6ELLtOIyrDSn2xfFWNqX2qwg5fzz4b7WQ1fv4u/HvBHc8UqCfgV4ZI0ALrMYJ0P/pEWGi9u4CR9gr33uey91eEMoeYINdAf4bk2315/u1vyGcFzlFvYDktJHdahxirhBfDJRgcQMXL47xlMUOcS5/uYGbKEOevKrLlfj/3UIfF8uiaHnAv1Hp5Gx/QTZBlmvuv+omuYEFUD+xnexQlSEuKgsjiz2WZB6YfiqO80ImH4W3fbQQ2pkuVcPSKbiRgqPpxAiTyGkqOJ41cutWp5EuOUNoU7653gE1pVSKmkxwZUx26jRD66B/eEDZXL4Su0/NhicyMZugU8TBCMA9HQd74ELJ4ZO12UVxHc4VdqVQjswbToP6pZFH/IFJZKE6mTMz+FvVKtRhVWrhpqmI5mXMqHlgavF7l+7DgSlDr8Kvp76yaSOsXhVuI+triy8GspqKlE4oF39z6xCsTsbbMIFHQDHlzZZz9wPCyQCobXdVEnxoSUbfAIABLgLbAlfoIDuPLSXBC/ke60RfvQo3o/uvqWZCGGPZyYaXku4HgwnzKJ3/QfNEt+4rXzcVmjomsrZyqfq93so8hR1GMUo1yH/O6m08irONNlIQNr3jSSJ8FXzpHC268GMCVlrrS5sAqO4OCzVmqyTtDpiZj7ZAKbuzwuiBO6RZDcXiriQ2q8y51w0zpWZVku+Gf2MTIPHPHBTRK4NxQ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Mar 20, 2025 at 08:05:26PM -0700, Darrick J. Wong wrote: > > So now applications need to be careful to not submit any direct-io & > > buffered-io in parallel with such above patterns on a raw block device, > > correct? That is what I would like to confirm. > > I think that's correct, and kind of horrifying if true. I wonder if > ->invalidate_folio might be a reasonable way to clear the uptodate bits > on the relevant parts of a large folio without having to split or remove > it? FWIW, I've always recommended not mixing DIO and buffered I/O, either for filesystems or block device. > > >> And IIUC, what Linux recommends is to never mix any kind of direct-io > > >> and buffered-io when doing I/O on raw block devices, but I cannot find > > >> this recommendation in any Documentation? So can someone please point me > > >> one where we recommend this? > > > > And this ^^^ >From the open(2) man page, in the NOTES section: Applications should avoid mixing O_DIRECT and normal I/O to the same file, and especially to overlap‐ ping byte regions in the same file. Even when the filesystem correctly handles the coherency issues in this situation, overall I/O throughput is likely to be slower than using either mode alone. Likewise, applications should avoid mixing mmap(2) of files with direct I/O to the same files. As I recall, in the eary days Linux's safety for DIO and Bufered I/O was best efforts, and other Unix system the recommendation to "don't mix the streams" was far stronger. Even if it works reliably for Linux, it's still something I recommend that people avoid if at all possible. - Ted