From patchwork Wed Nov 13 09:47:19 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 13895564 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 46112E77170 for ; Thu, 5 Dec 2024 15:27:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D309C6B00E4; Thu, 5 Dec 2024 10:19:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EE826B00AA; Thu, 5 Dec 2024 10:19:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A65E6B010E; Thu, 5 Dec 2024 10:19:12 -0500 (EST) 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 CC1666B00C4 for ; Wed, 13 Nov 2024 04:47:36 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 54FA48032A for ; Wed, 13 Nov 2024 09:47:36 +0000 (UTC) X-FDA: 82780592328.03.D993983 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf12.hostedemail.com (Postfix) with ESMTP id 33B234000B for ; Wed, 13 Nov 2024 09:47:14 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=snFQ0Z5P; spf=none (imf12.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=quarantine) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731491061; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=NogMAPzoSN85DvPt0N/0Cgk6QQiG18HIcIcgH/liG3k=; b=kvkAf3TKzuovagfHmrtL2bwJkP3xMHPC2D1/K0OsrhK6ANxE9oqG5kJHlZFXL++0GUYR6M KyxJPHyzL0opWfJGZmQFn6tA6XPzKa0us1hzckeOD7AgozYHQpC8r+qjWNxX9R4m6+WJdf C5yB3waCD5ES9YLyIUQRlXy6JCrrG9U= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=snFQ0Z5P; spf=none (imf12.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=quarantine) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731491061; a=rsa-sha256; cv=none; b=iW7McDxftbUPb3Dut6rEaMJlIz4pi/oN3NO/ZIHOvsfSx3goht4tf/O6C7KmE0wskjrSFR 6c/dhuNlsZwp37qClSFBeVm1Bb9FJPovH2X2yZr7I2yAb0zsUoJmGH2HxUNlMVfTq4AVYW 5S1m7GNEJ6IBoz4mYRKNK4VtwEJvbkI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:Content-Transfer-Encoding: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-Type: Content-ID:Content-Description:In-Reply-To:References; bh=NogMAPzoSN85DvPt0N/0Cgk6QQiG18HIcIcgH/liG3k=; b=snFQ0Z5PJlY9VkqMDtEFeSYgtD yMAPbpE4RgPcakyuL+8kKQyVKgjQ4rrp1V3uqsOWk6Nl53SQ3BZMdGLPQwiYA3iPjoR6fCmd7DaMb vamzErL4wJKX3d3LT5lvxfltNLq1g3j8gqFKiMbGhqsZV1s/RpohfYHIxH+luNGY7yMz0c1bs6kRe cpNKeilWuyF4a2Q8OQEy+FsWwCnS6M4Ld4IzUL7OEpDir3YxTWYoqW4nXJYfFTC/kwanqtuOiPgNJ zXhY/HPqdplSCnzxWhplwraESdUvvGzBj62+DaxWaV60NodWOsXDi7/YCaZ0XAkj1UoAlh/v+xh5N KLakTrOw==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tB9yC-00000006Hcw-32MC; Wed, 13 Nov 2024 09:47:28 +0000 From: Luis Chamberlain To: willy@infradead.org, hch@lst.de, hare@suse.de, david@fromorbit.com, djwong@kernel.org Cc: john.g.garry@oracle.com, ritesh.list@gmail.com, kbusch@kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com, kernel@pankajraghav.com, mcgrof@kernel.org Subject: [RFC 0/8] enable bs > ps for block devices Date: Wed, 13 Nov 2024 01:47:19 -0800 Message-ID: <20241113094727.1497722-1-mcgrof@kernel.org> X-Mailer: git-send-email 2.47.0 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 33B234000B X-Stat-Signature: 39c49kr6mk8ymsody7mroagsbhszzdt3 X-Rspamd-Pre-Result: action=add header; module=dmarc; Action set by DMARC X-Rspam: Yes X-HE-Tag: 1731491234-200969 X-HE-Meta: U2FsdGVkX19slKDJUpXFEx+9S1O8oX2BjOQ1+51xzI5+V03b/nFeWzkuOXM8MAbP3KTGSE3joKnesRyz5h+i6sE91pasqqnVyMn0K1KC9lvYDi4v7wZjYhxMlQ18FYHXpaGxAYOhObh2vXtDPUAsmtjy4SlzblP0lJvGzvIH2qboYwH/STtRs3Skj2rmuHlKxVsTnsL1GUGyiSDXVg6FPMFINypkRFSIzLn5WEgvZuTWSW/MCK1SMgjRrvRg2OK6cd73mkqADfaYn5PCHCz+eYj5M3OIEXIHlFFyWv4Zg1ctcO8lvk24xAyP3v6AdrPme/I41ICIk37qbzA19d8IzOssFtqyojbxq0Rfy5S1yzq3ekFOY2U+6iQ5XUsfnf0QHgeHiryRZUEFiE+dDRaO42eX9KtM1xGDYeyma0G4WwloQT/J9ZtfFn9pUeFSKovFOZtsIa/F4YUY+FkOqH0+WvtC1ZYrB/uu8XndBoXhvE9/mMXeJR0EnACez2PKxTwKlqb+2U7s6Bd6Xn7mmbu2RFeSdsP6nyBkPXbUtsgun/Jpe53RNXGEcKWA4Z0TgczrclSyYADUBqqS9fR2e/bY9OpsG3M/vvKU0ySnrTl/Brgw9L0zM27J//QG6A1yeb1u7tU0rJSYIxvxK3i0eORiDIJP664tDCpItQyDQVbREQPHw7tB20ERMG4DEOH8arRcz/IluyTrlafipGaDTWVbhfk0DhQuzr/yjt2z1yJcRbcL8hRHYSMdMrMmlRsmomORcS+52F7UkO6UFXBzn5z0H96lxloVUV8ihblnb9EMmDpSb2pvg9PkBh33st6ir3VprvD/tJnnQtUCl6t2SAkFDxMPzfcMRHkUXXRzlSCLAit9YXEQ0UzcLnm43e1YIQBmIkkrmdo/x4SX7ZSjdFNrYCXrtoo8hUaSxLh4QaDd/y4FvYYc9temd+0VzJgPdKuURTpF1qDcZqHRKUItDDI v/pKJchD g5D/AtdZvi4B27p2mTt2tSDwPlM9Jf2+OTiwAfiuLhKsdBt1TJgs9o5bDnEQ3NNfDsG03B7UiwC2um1g8Wn4i+r6HuQUBSBuMIUCU8xxSf+mfl4LhRN67IPntdlR7yOSOQBWbNH3sfX8R6QS+WoJ5Zb0qGtVteYCkwQj7ac7c5I/VKnXZHeiPN06uAWM3tUufPnbjmx9mUeHHuyDMRPt5EWDY9g1oCmzxNSvBFzMfhJhZKN5A05ndTniBwsafDFtkmPUUv66EebMkl3SM7WwFbEXFT6wZRA0wddIqg1tIUKOIoAITfsAtcdawSn5KgTxWqND40+J0YfbFdbzZdDuqdgyaNHr68GDNSmVqU5SnbKVbN95GW6ODu6dmLFzWCLlB70Wjq2b8MqY088sKek6rkeZkGfzgeMR5flo7x/HKKWZxV4W4mTb2giUGcBz1vU/K9TlZ9dIt+DtJwA2DE9M9UH7hHSyDbBjXZc+3sJdVbU0pcvJNgUyMbO6YQyPzYo4OTQ3xD7GatAxFN/acPjUz0U1OkQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000596, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: The last time this was addressed was at LFSMM this year in May [0] and before LBS was on its way upstream. LBS is now on v6.12 and so the delta required is much smaller now. Before the turkey massacre slows part of the world down, here's a refresh. Although Hannes' patches were in PATCH form, testing showed quickly that it wasn't quite ready yet. I've only done cursory testing so far but have also incorporated all of the fixes and feedback we could accumulate over time. And so I'm sticking to RFC to reflect that this still needs thorough testing. It at least does not crash for me yet and its a major rebase onto v6.12-rc7. The biggest changes now are these last patches: - block/bdev: lift block size restrictions and use common definition - nvme: remove superfluous block size check - bdev: use bdev_io_min() for statx block size The buffer-head pathces I think should be ready. If the consolidation of the max block size is good, perhaps we just also use it for the iomap max zero page too. Note that in theory we should be able to get up to a block size of 1 << (PAGE_SHIFT + MAX_PAGECACHE_ORDER), in practice testing that shows we need much more love [1] although prospects indeed show we should be able to get up to 2 MiB on x86_64. And so I think we should first reduce scope up to 64k for now, test all this, and then embark on the next 64k --> 2 MiB journey next. Thoughts? If you want this in a tree you can get this from the kdevops branch large-block-buffer-heads-for-next [2] [0] https://lore.kernel.org/all/20240514173900.62207-1-hare@kernel.org/ [1] https://github.com/linux-kdevops/linux/commit/266f2c700be55bdb5626d521230597673c83c91d#diff-79b436371fdb3ddf0e7ad9bd4c9afe05160f7953438e650a77519b882904c56bL272 [2] https://github.com/linux-kdevops/linux/tree/large-block-buffer-heads-for-next Hannes Reinecke (4): fs/mpage: use blocks_per_folio instead of blocks_per_page fs/mpage: avoid negative shift for large blocksize fs/buffer: restart block_read_full_folio() to avoid array overflow block/bdev: enable large folio support for large logical block sizes Luis Chamberlain (4): fs/buffer fs/mpage: remove large folio restriction block/bdev: lift block size restrictions and use common definition nvme: remove superfluous block size check bdev: use bdev_io_min() for statx block size block/bdev.c | 9 +++++--- drivers/nvme/host/core.c | 10 --------- fs/buffer.c | 21 ++++++++++++++---- fs/mpage.c | 47 +++++++++++++++++++--------------------- fs/stat.c | 2 +- include/linux/blkdev.h | 6 ++++- 6 files changed, 51 insertions(+), 44 deletions(-)