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 BAA40C28B30 for ; Thu, 20 Mar 2025 12:11:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 55C75280003; Thu, 20 Mar 2025 08:11:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 535F5280001; Thu, 20 Mar 2025 08:11:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FEA6280003; Thu, 20 Mar 2025 08:11:55 -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 235E9280001 for ; Thu, 20 Mar 2025 08:11:55 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8965F584DD for ; Thu, 20 Mar 2025 12:11:56 +0000 (UTC) X-FDA: 83241815832.20.373A762 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 0F18B10000A for ; Thu, 20 Mar 2025 12:11:52 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CYrG33lH; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742472713; 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=6GdYJvaUyHN33OWPLsIOGOvCIvn/uOWWV0lLG312V8w=; b=aUP6By5+nvgSZg+g1LV+OslqKj7ZCyN5+51e9mHfFIf3H2tJNkxxKicVqCtPievjCk6LGq S34awodFBDmvbDOKi/jv2+fxExvI8tm5N+bedTq22Hv8et1GH9xzkuNnFEVHE0nB3owdkn wJe2xl+4CK61723jSORt0utoiIXLZsA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742472713; a=rsa-sha256; cv=none; b=j13oPMMHadtUdI2mqjcn8wmJJAF4QHSItvuzdm3CgHB37HJcgUIH3cbYisp0mrjlo8ft9r R8slAoMp85LcOs7b6GOC1BhlmmVOZC6SFfn46FeH3Di3wiI3hDFZL/LpRQKgISNmLNubyN WpQKHeyR+jb8pHzEPXf7vb0hWDQ/GpY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CYrG33lH; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=6GdYJvaUyHN33OWPLsIOGOvCIvn/uOWWV0lLG312V8w=; b=CYrG33lHZUSnxCeeDL6buuQ3Gd ZXncxZYgvDt1AhMNMoxH0NNgwN2Vl/F9DMX+klnY+ql1Nb+wF/bNYyP/5zrijkmvfvPDldi/G/EXp KZ1Q1NnN3Rr8W5nTujHbkt3VZiKIH9ixxUui/KKTA3xtFqsZfx5lXXPq5W6wTx/2lpL8sWXxZKC4J TOdTSyTLt3BwtjJhMpAK7cx44jaEMtN5u4ZeVbRBcNzwzpAjKmCKA3scFSbMAUkwwPWRaK1TbSfTT ixPtmOV+j6xVtlwvDjX1uEPVjP7nTjGExNuYoIeZyhvmcGgOTeQaTXbjfMIkvYPuLHAk9OrzT0L5s orBbgBbA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tvEkV-0000000A7g4-2x1Q; Thu, 20 Mar 2025 12:11:47 +0000 Date: Thu, 20 Mar 2025 12:11:47 +0000 From: Matthew Wilcox To: Luis Chamberlain Cc: 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, djwong@kernel.org, john.g.garry@oracle.com, ritesh.list@gmail.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: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 0F18B10000A X-Stat-Signature: g9k1x6smaon6kmbeguab6msbzbidduxp X-HE-Tag: 1742472712-418515 X-HE-Meta: U2FsdGVkX19d1KmtzDuECsb2BQsT1Rkf4wOy91qZk36osoy/eE7SqhoEyvx8GFegt1dMzAiz1A3/ideG0qm6tURqCw/UsbvF51FI76HSesmjjCC3Vc6AcnzBh/s78J0hRvRWxgDtLRIlEWn3J86jlc7ksUTBUxK1KFNJuHIYE8L+uNWpDGdNfKImqGGJyY10SQ7qei1n4BJfLpIxt5lEuijPt7pN+JaQHBYf9GxJq6UgNrtE5Vi4p8I4ysmRl4/m5+wo7XnI6CV4xTLS7CnvDinYWn1D7HTmQU/i5QnhJ2fG/YFXXUYaLbUCh7E62cAzGn5B+oLDjPPwnVT9OsfRq/9nCyxZ/1DPMKGpkNGwuicnqZyRJU8Cz/cpUkgJ/m1Om7jjQwEdWlv8xWPq674WGgVfCvAioYijqb77CrVVpTDeLKgT3+O8jOU6tCg6+ZR78QXF5SS/cxjp1URZvJRQwZ3X+4EVdSGrxao6yA8BVNUM9Gcj1Ga4d7cvAya7xS3aecqRRwGXk6HTA/5Gge9559GC2NA6awn4uvYnMkjDFQ8uYOzWawaecI3VVoGTNk2DyVbBogLKXGNuPmOF08YYGNzeW2ChRd4Ugg1RI271XGqYPZG+uIT/9a4fnQIZ/nMieOnZgwi3V6VX/YngwpFeDc0MApZY7lC27a29kd3gRfGqeJgdVMLz38DRfoIOBsPkLrpI8sUyVyJdEmb1FIX8nC+BitLLIR8BPZSLHFfz6sK+oJq7ivbFUPmCVJfzHXj7NZt3UONxKtV4fzlGofEYqdhE0t/W41WLlZvdC0i9no/FbY53yNm0+m7HY+HzwBqBIHEQk5yiQQBeHgNdewBGkzWOwczzxUa/YcvmMxvLzLz/7ZO1M69DmEFDCJ44zbedhLTODTQ8Q3bL2sBw4KhmJj2Eq1qUdnvduSIy4ON6Ta1cDiLP77qYG/OAM2MuFuc0ONrgyEDiUtYblqFZks/ kIhw3Cg6 /ZuqibnrL739rOKA9IIsVtON8hVL7uQ+d1hfE7ISRZwLPa4qup8MFnp3g+6cjp8Tbelyi7xMmfthf6A+VnCPlY8xTfozunqcc7YMPGZf2y6vh+KG4kd88H221jEnVdtaTF+hYXc3Omz4adpdhy5Bhl1Y7f9gxsXp7OH+sN+OzJVxeQXiW/zaIzNFeIOVg1QPFt11ajNTeIDKxcKcOMfQO1a/0rdaLzCbJZYnUrJzV+F6d4Ixt+OAupjYY0WLJx/xL9CjcjJWP6Os4RwWKBXJYD2pTNmrVPMgaCWzre2Wn4w8oWKBJdBo8HoDCtrwuTYJa/jduOygBYbttJ03vCPWPIdYIGSX9dSA1bWWv 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 04:41:11AM -0700, Luis Chamberlain wrote: > We've been constrained to a max single 512 KiB IO for a while now on x86_64. ... > It does beg a few questions: > > - How are we computing the new max single IO anyway? Are we really > bounded only by what devices support? > - Do we believe this is the step in the right direction? > - Is 2 MiB a sensible max block sector size limit for the next few years? > - What other considerations should we have? > - Do we want something more deterministic for large folios for direct IO? Is the 512KiB limit one that real programs actually hit? Would we see any benefit from increasing it? A high end NVMe device has a bandwidth limit around 10GB/s, so that's reached around 20k IOPS, which is almost laughably low.