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 105D9C36000 for ; Fri, 21 Mar 2025 18:55:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24744280002; Fri, 21 Mar 2025 14:55:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F3AD280001; Fri, 21 Mar 2025 14:55:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E47B280002; Fri, 21 Mar 2025 14:55:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E4431280001 for ; Fri, 21 Mar 2025 14:55:57 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A23C7160588 for ; Fri, 21 Mar 2025 18:55:58 +0000 (UTC) X-FDA: 83246462796.26.0406A19 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id 12DF61C000D for ; Fri, 21 Mar 2025 18:55:55 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mciTbD0Q; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of kbusch@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kbusch@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742583356; a=rsa-sha256; cv=none; b=ZIRP3JypOwo/sPxv6qwS+Lwyd48APxizGxvlUclY8fEFotLpaQhoQLyCGnRwMuQyNB2wzj KKeiYS4pBYz+X0xqssytP0465fCKRcAL71XguBAF/kU5jjgxEMls0STBrGp3gSpcD0qZI5 PmeQHh6X2jMg3omM3P4bgEsi/Zq0sw0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mciTbD0Q; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of kbusch@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kbusch@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742583356; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eFJ3OLjAIKpxbQiJpEH/5QEkJzNOzssuNjlCoczo9vY=; b=IxgtNEZpU2W4Q4kmOSy0nRc2o4okYr/mD9ZOVptOGaaSwlHPsnJZ67qr9BwENA7WmVYSv2 koU2KB+CsZ6CTGsg03RFaLAO1wV7RB6tGtQoCLG2n4gqJWepvh3KVq5XZQ+/dbS6D1hRIl wBwZ9eX/s6p/xPkiPXpK8dCBzGVlnE8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id BFB1C5C6E4D; Fri, 21 Mar 2025 18:53:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2523EC4CEE3; Fri, 21 Mar 2025 18:55:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742583354; bh=w12rCUpRRlnFTNDJ/U+SOBnCtlzfICVSlsh9Ym7O+N4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mciTbD0QQWuzPYUfOwXAUqDo8vvOxxP4h1FybYtQps1Ml6nc6+GuqlUuaq474IyCb qPVXquzW/I8Lqh2hW1ldeU8dvn9TcssCJ3Z5EzFodUAdD8ZZVjTFvMKDb7PdJx4NfC oN3Kq6g5leHeKGI41L4kjf/3RzKH+M4PqM/M1WfDS+tqTlVOrjEtCKqn7IF3z1PENf q49KujEicQYs5UW5Pagu/nx2tJ4mbcovq0jbMskM/JRnmWEsGj8MCi+3lgvxwmBSeH H463quHsqCTgSJNNDMrWLsaYihg9lfrjI29jYFMGiM8U7tL4LAXO1S5OWKSTQq+Ox1 q5tHryGzSQmZQ== Date: Fri, 21 Mar 2025 12:55:50 -0600 From: Keith Busch To: Ritesh Harjani Cc: "Darrick J. Wong" , 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, 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: References: <87o6xvsfp7.fsf@gmail.com> <20250320213034.GG2803730@frogsfrogsfrogs> <87jz8jrv0q.fsf@gmail.com> <87frj6s3ix.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87frj6s3ix.fsf@gmail.com> X-Rspamd-Queue-Id: 12DF61C000D X-Stat-Signature: tjsjfb7jpenc8ttgpg3iswo77sb4k71n X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1742583355-36841 X-HE-Meta: U2FsdGVkX1+Yq4VEAypHBrCtQD40n700/9BSOOA1pp+lGq4nCwncVtK8ONvSRa5M50aciDcRKOuNIR2P6yPIuQ+JrA8UXRGk7+WoiUN1jxDlyBfWk788+wS5rBzuG2tcHaUNRIfe2KZHIwZNSflUB5LRndfhEBwPt/kUge+Nmo7oI3wZb+T55KxREp966N9XuBQ34JXyH3A7yytjR81/MX0q21aIzPdkkDXNxpqn5sNxkIvAdlAf/fZ9Y50tGh8WTvCZCnxjY02id4p5uMmuNTRtzjpC1vp7ZBM++fcbiOmLWDA5dFi/+lWWTJNzwXlOhwXjAtKnDBmQafF1OGjgQONFHkhz8DvmNcQCWrs5CLBbOVeELVrwoi3EGPjfLv5EyG5s5q8n9L7c/zVEWgQYLSitZRhURnt0lba/oTb8b/jW2AQAWrc9dPO6CYJ5PtgoqUMV+NX3ZQ11IcJrGllDBxlwi5el+nHOka/2ouVZ7fjhp8vG1WZA1pRTl55pdwSYo0AVlcsjZ9iXAhGE+aHAbiU5yxtRuzBI1sEYobcE38Bjhd+YwJGjatW2HbDQk5OtEQOPHoregYn+RbQabyjowgScfizu1xZmpUdnW5g+n7FLy7E/eypoXVYkgseyq4w2l0I8xQksuKZrrJReLuYrBxg9jYmblZ//ogwYr4v8nR3N0GJofkGDoBlOt5I5g035TOyNpVnlaNK+JvftcBdPcvm799KrmmymybuNqVNoX3Y9mMtvfIQdRlbCi1ATvtS0bTx8xwPfvhdoOHxDg13XbCO8GtGi++jDgkD3ExMsHeTUNI9tI/jWXASMgskQEkrkJUrFN6gyq9vDt82qbLGAeMeXPLifmn2OfTBm/iKO1C4Vd2LgUQaIsuVviH6Nb3QVr8iBzWVEys2YTElMbYvWvZZ/dkrWnsTaNDFxMwzEcslmbBaJQW2T91BJUcyPsX5N/7Ox+ehuYTMQIxyf/z/ eauhfmih pkN/jDe0k43ke/TnkeZ5FdQxGGq5CKo4e8hkHOiDZs95LFdmIUUbizy+JCpVj9lotupOs18dIpJt0u0HwupZtcdNaaNcp/mhk8h1XtbRRNpuMS6hBFgzXfmBblcM8rXlatLHlQa49Q8/udVjzAB3kCOqmVyKVBNtcD5tncKuUWyNTkIru7Hk28R50JpqPsBRb19w9oZwyvz/IrXObfPBeR3LlSytXclO62MNPBCWKq0nzS3tA7HT6Rb8gREYjPEH+U0ngdZ8yLh4tgFpxeG6gywuPLOW3gQrRzhf1lJ1lc5Val3nwUpDBjpFgdyQTQwgwo7xnPh1bl2dbR5QGsvxtTXfNxb+ztTbAvddi+fJjeOCoGmIa4EkiAw4G4FOTx8C7nQt7mA3vHlssJ40= 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 Fri, Mar 21, 2025 at 10:51:42PM +0530, Ritesh Harjani wrote: > Keith Busch writes: > > > On Fri, Mar 21, 2025 at 07:43:09AM +0530, Ritesh Harjani wrote: > >> i.e. w/o large folios in block devices one could do direct-io & > >> buffered-io in parallel even just next to each other (assuming 4k pagesize). > >> > >> |4k-direct-io | 4k-buffered-io | > >> > >> > >> However with large folios now supported in buffered-io path for block > >> devices, the application cannot submit such direct-io + buffered-io > >> pattern in parallel. Since direct-io can end up invalidating the folio > >> spanning over it's 4k range, on which buffered-io is in progress. > > > > Why would buffered io span more than the 4k range here? You're talking > > to the raw block device in both cases, so they have the exact same > > logical block size alignment. Why is buffered io allocating beyond > > the logical size granularity? > > This can happen in following 2 cases - > 1. System's page size is 64k. Then even though the logical block size > granularity for buffered-io is set to 4k (blockdev --setbsz 4k > /dev/sdc), it still will instantiate a 64k page in the page cache. But that already happens without large folio support, so I wasn't considering that here. > 2. Second is the recent case where (correct me if I am wrong) we now > have large folio support for block devices. So here again we can > instantiate a large folio in the page cache where buffered-io is in > progress correct? (say a previous read causes a readahead and installs a > large folio in that region). Or even iomap_write_iter() these days tries > to first allocate a chunk of size mapping_max_folio_size(). Okay, I am also not sure on what happens for this part on speculative allocations.