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 BE9C6C4167B for ; Sun, 3 Dec 2023 21:28:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE69D6B029A; Sun, 3 Dec 2023 16:28:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C96DB6B029C; Sun, 3 Dec 2023 16:28:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B861F6B029D; Sun, 3 Dec 2023 16:28:06 -0500 (EST) 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 A6BF96B029A for ; Sun, 3 Dec 2023 16:28:06 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4059B1A0197 for ; Sun, 3 Dec 2023 21:28:06 +0000 (UTC) X-FDA: 81526794972.03.71B7F01 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id 00B384000E for ; Sun, 3 Dec 2023 21:28:03 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=XdMcWrW7; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701638884; 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=T78NYOSEdis+VzY5gp3O6MA8KLiyzf1kByHBipMMA5o=; b=B5/A4duSjfofY8qfEE2idgorwficOgxS8yQlRQffo0nzmXg3REK/ENDL3+0mgBDIlghNkc ImW8ZD5hwGyga0VoLh71hO9E2sROGldxbb8Va+hx/Wnjeh5jalgzB90pYL652JQQa1RhPs 1og1RvKYMbPdr+p+CFDSAr2WFn6uwT4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=XdMcWrW7; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701638884; a=rsa-sha256; cv=none; b=Nkrit5Ek1QUT4BFO4ku/2i09SVk0sfb0PCHBXHhiNaSfIV9UvXtGM8S1xkCCdbDxGSdDkr LyuT650sh3vhWRA7qgFvf21ig3DXthsKgmGsmgf0zXQ/HrRUlXfSb36odo4XCyTduUq+9l zzrGEtLgzVySsHAJC/pMpuVrik6wqKs= 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=T78NYOSEdis+VzY5gp3O6MA8KLiyzf1kByHBipMMA5o=; b=XdMcWrW7o51kVJ7ySQNIkTbmqW K6Dk2DzuGRJr1R8UHPGHly2w1/2MF02nZpZ+N++Cj9xiw5HHmksj40tXlrEIegQBvGRP9y11Cq5xk lGw5ewzvs+7pkzMLiauJUrRSVBVtLtK9YCjEuv0fQr1X3VS8hI+Ih2YI5oRMF/oLQ7Da9kVKtjHwo Rtyzht7CxxkPloZMZZ9RjlwOMeN8xnSyvhdGLBeWHJid22CBwBJ8UDus4zUj/sPNY+r8MDeqVyM6K cmg8Co+FRdEVJPYBVVVPynilE2w2sG9BxUbQnJAY176jvvWiCwHa9M2Wt0RN6G/6s1fTOvugEcaay XNJrBs2w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r9u0L-0004nv-Bg; Sun, 03 Dec 2023 21:27:57 +0000 Date: Sun, 3 Dec 2023 21:27:57 +0000 From: Matthew Wilcox To: Viacheslav Dubeyko Cc: Linux FS Devel , linux-mm@kvack.org Subject: Re: Issue with 8K folio size in __filemap_get_folio() Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 00B384000E X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: kt79s7idiokqpycsm3ygar3ewqwayuk9 X-HE-Tag: 1701638883-483346 X-HE-Meta: U2FsdGVkX19rVeoN6+lcQZ7eh7/MrD8ZYuzWYCN/YuQAjJIZvwykUO7Q8cs5R3ftRJbBBGgOpvtO33tigE2wRkcFzlRXFHsYWMYP6B9BuIJUROCJpFarQosRGU0ahb1sARRxKkwo3muABR9BWIBBWjeVTOzKJ3bV0YA/fyJWpvPkWAKsWuyhCQ1fGPSJZ1TnYaKxnRpUxsI6HiIJuZqiPwlIc2KyRTo3o13h0bP9ib2IZ5BTew1n6Y6HfQhLXhm3GHYitfAcA5px2EmN+XbPGle/Lr/SOFb29WX5gzlIH9nFOykZ/cNNH3EmohjV5JQUQvnVQxBfdCer5vruCt6yxPkYN/4683kQgj+XBd1hyP4aRzcMd/CQh5jTK/ayEUQn+07JqrTuNuzzNnsLdFqgsaRfcyyIjA1oGo5y2jsPcShciSNPTVcE1Jk/UUYpcNn9DvqOMqEYwt+t1zaiHh1lfRNNE2fgO7Ny4c33iJ5xTmdTU4PqOfq/A7MPbxXzn2Qnlbjp+8YLH6CEDNzFczT6o0Dmq2FkU9QXEd75uHqnbrC/rLID0gQFPfZb6ev7rWk//rzSqB768Gtoa4HWy6pwj6EZUw3aNR3Pkirp87QjN1yyBaEl1IKUqoJj1vgnCYKoPqsG9mcqTLZzkAGjgRmKFhqiXsGNT9SGUkuJPt9LIAKhXaox1sGZuJoWuI0Ry3E63mk85d5zlMe3CHR18aSFyybNWAK3d6HIp+mZs0nP7bE1+Od65FkwREwxLEby1T4YkY7YIaMxqbjPmM9SExAyO+RT6vliqlh60PGxEt1CyvosnlnYMTctFu4N3SPpAO7MdVopOvSa21OL2bkUo9slZAUU1KFEXcweXepgTrAAel4KcAw9Lvl0N9Cxmo0EFjpV8/EJvh11jyGXK8Na5zNByzbgV2e1SxYWna/VpuFdC9jg55Ig3vmkYL8EYhjTvMvVNHavhpVIHu4It/lg1bi 1PR8NbMe 88RG6/+bLo3qSTcihGmaRnckhgQK3NhrpUS3D/gycdHG6/aK9pg04l/t/e3hMiLVbSdaH8w63yq1I1qU2b70Kgi3JXGcah/k5/5NggGgjmUyVP6Nx5x2XAho0+mRSx+Vpf+t+N00gEwSCUDZwLNJMBjMpReIPzCBIaqslQ4Ua6ggmz8kvmlHD8RIWiA== 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 Sun, Dec 03, 2023 at 11:11:14PM +0300, Viacheslav Dubeyko wrote: > So, why do we correct the order to zero always if order is equal to one? > It sounds for me like incorrect logic. Even if we consider the troubles > with memory allocation, then we will try allocate, for example, 16K, exclude 8K, > and, finally, will try to allocate 4K. This logic puzzles me anyway. > Do I miss something here? The problem I'm trying to avoid is that when we allocate an order-1 folio, we only have two struct pages for the folio. At the moment, we have the deferred_list stored in the third struct page of the folio. There isn't quite space to squeeze it into the second struct page on 32-bit systems -- we have _flags_1 flags _head_1 lru.head _folio_avail lru.tail _entire_mapcount mapping _nr_pages_mapped index _pincount private after that we'd start to collide with _mapcount (which is still used per-page) and _refcount (which must be 0 on tail pages). We have one word available (_folio_avail), but we'd need two to fit in a list_head. We might be able to reengineer things so that we don't need a list_head for deferred_list. eg we could store deferred-split folios in an xarray and only store the index in the folio. Or we could decline to deferred-split folios that are order-1. I haven't looked into it in detail, but I feel like this might be an acceptable approach. I was talking with Darrick on Friday and he convinced me that this is something we're going to need to fix sooner rather than later for the benefit of devices with block size 8kB. So it's definitely on my todo list, but I haven't investigated in any detail yet. Thanks for raising the issue; it gave me a good opportunity to explain my current thinking on the problem. Adding linux-mm for insights from the MM audience.