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 F3027C77B72 for ; Fri, 14 Apr 2023 14:38:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E6016B0075; Fri, 14 Apr 2023 10:38:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66F116B0078; Fri, 14 Apr 2023 10:38:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 537B7280001; Fri, 14 Apr 2023 10:38:42 -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 368D36B0075 for ; Fri, 14 Apr 2023 10:38:42 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CD90C80372 for ; Fri, 14 Apr 2023 14:38:41 +0000 (UTC) X-FDA: 80680252842.30.06EC17C Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf27.hostedemail.com (Postfix) with ESMTP id 2B4B84001F for ; Fri, 14 Apr 2023 14:38:38 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681483119; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Yi+ZzBkglvsQriQ0EREIL2/HYaB0jnz90sM3ahQbo/U=; b=SHH5lfqk8t7vfKgqTU3EMGyL0DVCYLDaHVs6JwNdiIN+mEdNIufu2DDO7lmI4+zjjz5ZEU L7kkRMM+bHPEzLSv0WqnyS8lg98xpBUuLVfNmxjmlPQs2vDhr5QwdPYeghtHFopVPYvRyX xZD2TwlJPCn/wbfilavbbdBv7nwxzNk= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681483119; a=rsa-sha256; cv=none; b=tZpfbxMk2j73UV3nueGp13InM+13Un7CqvxKlusqs7i9UmF3iPdc+aIKBYLse7HVdv1o1c +49KsbnZCFgT00L0i+1rKJd0RnJW2DKXpRl4Zewf+KBfIHrCsYExQz8tmfakZSffe74Yy3 qt+DQsbGe9UNnRVuykSt5pRdEEb1t3Y= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7BE572F4; Fri, 14 Apr 2023 07:39:22 -0700 (PDT) Received: from [10.57.68.227] (unknown [10.57.68.227]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EE1433F6C4; Fri, 14 Apr 2023 07:38:36 -0700 (PDT) Message-ID: <2b76ee7e-06d1-94ca-d22e-46b6302b7c30@arm.com> Date: Fri, 14 Apr 2023 15:38:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [RFC v2 PATCH 05/17] mm: Routines to determine max anon folio allocation order Content-Language: en-US To: "Kirill A. Shutemov" Cc: Andrew Morton , "Matthew Wilcox (Oracle)" , Yu Zhao , "Yin, Fengwei" , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org References: <20230414130303.2345383-1-ryan.roberts@arm.com> <20230414130303.2345383-6-ryan.roberts@arm.com> <20230414140948.7pcaz6niyr2tpa7s@box.shutemov.name> From: Ryan Roberts In-Reply-To: <20230414140948.7pcaz6niyr2tpa7s@box.shutemov.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: prduemk7xtspniogitpt6rdycyutjp6h X-Rspamd-Queue-Id: 2B4B84001F X-HE-Tag: 1681483118-79168 X-HE-Meta: U2FsdGVkX18ZuwrnHBQV6B6e+nDr+IyRzeYJYMu83ZgqYdgFSAul/lcWqTFlID8VIGKjn6NtypZqD6w/5TvIvfnlrf51huG7gNFuyfiMkJdjbDcoZpYyNWYl/vxaN8OzbjUPj7jVdOROftqb9RX7bCGXA2mg+ad+DL2iHiw01QU901Q/BUd0eRvdXnGS3rp9BGJB/3YDbcKvfup046SQ6T2ifELxtoXSJb9B3MNZMd4lssvOWmNP4YTKZKt3nTUi0e5z2f+c7wNXRbIcx1C/Y7UMdwwscOn/QR4ahKk/2dDLefgGTvMfepR7Syon5rkk2BsTFxR3lmSqtEQR2npz2PRJykHjsmqkpt9u36h8xgZUwTBNuWmvtKnQXzS+M1W2yyNzmieMTcl9YTTC/gOk1uZ1OUJ0Mpnxf5tBhrxYV9WJmdZfy6bwNG8Yobxq4SxN/lKPDhmcf8/5nu7SeQ6Uw+lNn6vkOL+QULb4uwZKExeozRY8ldCRimNPtk63AH0RSXKHkmEt6L1WP7qJyQiWAtc9sfvY9J+lPkhYJnWiOLH4ZUNwmPyMqwGvEHSnEVpnMtVYqysIYnVMpZ1kwCCJxu1TqWyrc1EVM409fXp2+yQi4qogFn0GFRbHvKrbOyf6YYjuHQrEivlO+fDhHhlgdw38SNsLhJ7dsrD14aT+7EtB8iYf26d6EwYXeKu/5Cpyvsnr9tY7xyzugVazHNv+VepkZk6B4fanmgr8UyGIfCkFHWyIhNixKT7gln58tsoRy8kHkV1cerIhPRKWkW/8WwD5y7gmiFcoQqYhGI1X6LAGmZC42F/s/peh6AqDF0NJO3riBvmYEFzmWTzIwIv+5sOf89HlKfb2+5GhW+NdZb5BaOxqbcWfYha/4hGIevH5R3WmnGieTdPuo7DAzaCJuwy+jSHwr1yBwjdJmybnGDshRPviyFB0EdDdj16ZUmu39DBvJapKIOd5h85hbZP tFFRP/ju bMIHKvIG7mkkkdv+zYGRQB7uMoQ0rlajR8joKDbXAViGnxBWyyuSfi/g2z2OxpRqcqLqusPX6ElOKTjnryAw6fJD/N/k3955uadQdLiZHbroS6kJ4z+TLmY1oH6MHzrEX+obGW8Cxib2naju3+QtM8zNbZDjJkZkj3y7ii/sIOJbcoT2y81Kx+oBiXg== 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: On 14/04/2023 15:09, Kirill A. Shutemov wrote: > On Fri, Apr 14, 2023 at 02:02:51PM +0100, Ryan Roberts wrote: >> For variable-order anonymous folios, we want to tune the order that we >> prefer to allocate based on the vma. Add the routines to manage that >> heuristic. >> >> TODO: Currently we always use the global maximum. Add per-vma logic! >> >> Signed-off-by: Ryan Roberts >> --- >> include/linux/mm.h | 5 +++++ >> mm/memory.c | 8 ++++++++ >> 2 files changed, 13 insertions(+) >> >> diff --git a/include/linux/mm.h b/include/linux/mm.h >> index cdb8c6031d0f..cc8d0b239116 100644 >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> @@ -3674,4 +3674,9 @@ madvise_set_anon_name(struct mm_struct *mm, unsigned long start, >> } >> #endif >> >> +/* >> + * TODO: Should this be set per-architecture? >> + */ >> +#define ANON_FOLIO_ORDER_MAX 4 >> + > > I think it has to be derived from size in bytes, not directly specifies > page order. For 4K pages, order 4 is 64k and for 64k pages it is 1M. > Yes I see where you are coming from. What's your feel for what a sensible upper bound in bytes is? My difficulty is that I would like to be able to use this allocation mechanism to enable using the "contiguous bit" on arm64; that's a set of contiguous PTEs that are mapped to physically contiguous memory, and the HW can use that hint to coalesce the TLB entries. For 4KB pages, the contig size is 64KB (order-4), so that works nicely. But for 16KB and 64KB pages, its 2MB (order-7 and order-5 respectively). Do you think allocating 2MB pages here is going to lead to too much memory wastage?