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 C6C42C3DA6E for ; Sat, 23 Dec 2023 06:09:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 138996B006E; Sat, 23 Dec 2023 01:09:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E9536B0071; Sat, 23 Dec 2023 01:09:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F1A0B6B0072; Sat, 23 Dec 2023 01:09:30 -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 E318B6B006E for ; Sat, 23 Dec 2023 01:09:30 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B4BE9160833 for ; Sat, 23 Dec 2023 06:09:30 +0000 (UTC) X-FDA: 81597056100.26.403D112 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 1AB86C0002 for ; Sat, 23 Dec 2023 06:09:27 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=iofxtKSh; spf=none (imf22.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=1703311768; 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=FIfd7D9NcYU+tLRC2jD8qzUw52wN1jMqZELxCVZB0E0=; b=rKnX3jMVKbKZi0qeAPm/+RlVDWQK4cclcauz4NL7VWu75hKTHnbHES8cdF6hx8k3Gi1mek Be9VzzMYA6VQwvnIHQMeXd8scEvmCTedFFW3dVEnHvgZJyVjJWhTk7VQ779NdM1jsLBHoQ AGoSpVouUMnIw+IvFevV7wcfhSlX+WI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703311768; a=rsa-sha256; cv=none; b=Z8JOUGbnon0z33a/OCv98zR3NHI/V1PbR4IV76TebjAH8JaoPskwL8MKvRqkh/qmF1QD+4 eZxKoC4bZMDZdgTcJofz/IW43fjRR87q4vECZcuvUJv2DPUPE7JrLd20Eas+B3wcjnxpCj uiYXKJzj/reA1RURkn0ymmMS55ErHwc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=iofxtKSh; spf=none (imf22.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=FIfd7D9NcYU+tLRC2jD8qzUw52wN1jMqZELxCVZB0E0=; b=iofxtKShujXTU42NF+bJH5irBS mWMi2eHKNo9H5Rr0d8OPZHW+d+fLjc3vTkt05VGPNcxGGU/lLTuuJmw2eQvWeHe9XaKu4f1aBuzZ5 tEK7GszlC0G8D9BbdsHMyt2aFBivFOKntA+5DdVWewUGe/EZcTNM/p5x+sRNgwIDrc6lppd6n4Vdf +ZNdniZsT3AiacyOreJI3m+K8+Xy28Z9s7mdSSNV+VGOcxaJSAtzqJu1TLSIyJUx1b2pboKP4IvPY PbDUGQA18HefWBCXnePz+O5fqAIy9U+e6hUKi5xOEkmlnunP6hlP9ow5PE2emX5Kjrov1b9/ccRlF di96ElyQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rGvCM-00A1jK-0n; Sat, 23 Dec 2023 06:09:22 +0000 Date: Sat, 23 Dec 2023 06:09:21 +0000 From: Matthew Wilcox To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Andrew Morton , linux-mm@kvack.org, Johannes Weiner , Vlastimil Babka Subject: Re: [PATCH 2/4] slab: Convert __kmalloc_large_node() and free_large_kmalloc() to use folios Message-ID: References: <20231222202807.2135717-1-willy@infradead.org> <20231222202807.2135717-3-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 1AB86C0002 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: idz89hz7rxn66srgpi6mt9chxnbnkn3u X-HE-Tag: 1703311767-506908 X-HE-Meta: U2FsdGVkX18uOXbwE4eLy5T5t3xA5iERPh5JxtGhrBL1tVfjCl8xHM7mXJiWCciuLZOu54V/DsUjibvg5y9yKM8TZ96BrBzOV7VKntBOEWg/EHelK8FBzFFD1rCTwK0Hn8n/rkqNKRwDgQYY+LHBZuOzzMaJtTfyYEqVBDQ97qtYacVMW+8vxZRvSzozrQ2/aiXW2pSUZEI6ivUoqWR8aKydpoJIIBJwA7C27wWR2P7FYgS9fkr1p5SddQQDx2mg+9WeHB3ZVEQpGOHv+QnWXowASuabyY/zhkZn8NMbV3CpCbV8CEXWyUBhXhqWwPiCGoRfCa79EX/MIcz8npIbM6c0v/6szTx0KR52vpcVZKBH5/+Vo4grY4DtYiFceNNstAWT3FlKeBCpZwbbgaz0jCZB6a475bSWIX0hLi2blLyHmTuQvqKlSFa01iJfdEare/ADhdhmHQ1XyWAjMFULuwSMLcVm6y4p2Sf0FarhsXhl0PdbROsm9clEFK84bHQg15vZGLjq1SshZLLfSQPx+J6yHZ5yI/bLEBWyp/iHB07tbjtik/IprC+TSDuS7UKzg63rDV7g4DRoDrhnrvHdYgHpilx8Ct9Fk1le6sjNwzwbtfOXl4CM8wrLTLhHp5g8n4DCAHeulmBQfctmRari56MLdyfzz4qhzl2iOecUheKKPI3Jg4age+JSL8fbOrG0hqO+ZQYF0kNLO34+WiTGf5FYei6DbpYCWwDvGkj7EF++Tr9ijaiC5iRDWQlHxrp6si33fF0MSDzl4yQUdlY3MtvQv0naeEtcidIWUUokxpU6eJxhEYCI5nD+Y3H6NSmVwdzfNM9RyOJX2uE2ZqEEJaLxR2SCfFKhJn5MhsnJmfsY/2gpDAmx1XJw7f0WU6XuwsNvh9S5e4GNwut0zYwcoUfV6DoKQpxIsnKxOAOUn5+1O1MwsGZnebL6SNYb/KUpLCShXlTzpePkhsupfqI dY+QjXqL r/mHUPV1IGiyd6RSZJxlj7Vub+iBsnNdlaAtShGnMbdw4KI/DOTsmKrtAJ6KL3Oh5gUYTot/uFXKP/hdNSQfeHRJ99X2HMG90ZDRqmwhJzhE4ff5k9ANto3oh4h1svNgFwg02TKTklDFvl+4O8dHqfxYnwMVb26MzTolBhm056IzQBgxTWxz1+RBG+ysnfkXdU3/f5LEzkQ7G8Hsktfc/OFOfonXk7Mr3N82wT8jFgW9Ua423bnm90SqRQfmSpEal5hA8 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 Sat, Dec 23, 2023 at 08:11:11AM +0900, Hyeonggon Yoo wrote: > > + folio = folio_alloc_node(flags, order, node); > > folio_alloc_node() > ->__folio_alloc_node() > ->__folio_alloc() > ->page_rmappable_folio() > ->folio_prep_large_rmappable() > > I think it's not intentional to call this? I've been thinking about this, and obviously I got bitten by two of the meanings of folio (both "not a tail page" and "mmapable memory"). And that leads me to thinking about how this will look when we allocate memdescs separately from pages. I don't think we should try to keep memcg_data at the same offset in struct slab and struct folio (once we're out of our current transitional period). So we need to stop casting from folio to slab and vice versa. Which means that slab can't call __lruvec_stat_mod_folio(). I'll try and get something together to support this, both for the current layout and once memdescs are separated from struct page.