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 EC7A3EB64DD for ; Thu, 6 Jul 2023 19:33:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BD246B0072; Thu, 6 Jul 2023 15:33:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4770F6B0074; Thu, 6 Jul 2023 15:33:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 334AB8D0001; Thu, 6 Jul 2023 15:33:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 21F4E6B0072 for ; Thu, 6 Jul 2023 15:33:41 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9244E80C7A for ; Thu, 6 Jul 2023 19:33:40 +0000 (UTC) X-FDA: 80982186600.04.19C7603 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id 43BA68000B for ; Thu, 6 Jul 2023 19:33:37 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=kdCQhoZR; spf=none (imf30.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=1688672018; 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=0wxmw1h/+sc7ZkGjLi6C59U1J1wukIjy+nrYU+ZKh7s=; b=rr/a9QkL4O8GS3Fl03IOgCFEGHWJ9kO9D4bQFlJH9js9EnwuDzQx6BdRZjXf8Xl3xVID+K 3R4Q4LsrhItIq+Qgf4Ar/TodDRssYtAcMp4JJZ6Ka3mlNK3LJCZvHDCdoW03wzVjiXHEBW bwjIYSR6FiLSc0sqZJKbEyRtsv9oUzU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688672018; a=rsa-sha256; cv=none; b=NmVnDQs/fWDBBdC8EQvJiCzOw2m1OySHD/TmSlp6F8Ch1h6hrMYU1MDhZqJfmbSboSvrgg xHHj/NcNr8JrpBmjSeVZWaU81HGu8qNoyM572bGH5P+xIotsp/cHA8i+bOsoLOuxCqTfAZ rBXyzRNcaxEhsQzcA5xY+HOt6IRXC7c= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=kdCQhoZR; spf=none (imf30.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=0wxmw1h/+sc7ZkGjLi6C59U1J1wukIjy+nrYU+ZKh7s=; b=kdCQhoZRlP+51y/fm7OjLLXVUU MgnblWPjJeWegHqTxc2bW0g5qPTx6NwuwQCIsIJvqXFS5nAz/OseFxEljm4ZSBVx8ZlGklmk3j+yG paqL/h+GOK0chawhP5ibXNRWszLaLGTJyhS9KS4VaS0kGn47IFSlMOdqcxAbPvjLFkao/7Loxweav zMDn7iZYkB5P64QhmKHix+FMnDemyQSDfb0d1ZqkosI0J7H/lbDLI1aJtQ7gsetgEhHDK/r3Cdsu2 RKI9G5Uq2Ymp6A4iOE5hCZOGQCfwbDECKx7oEJ4/xr55VGX0rlMmt/CEdFA3HhBJvEKIA8HxXwpja SxnltGVw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qHUj7-00BLN7-QK; Thu, 06 Jul 2023 19:33:17 +0000 Date: Thu, 6 Jul 2023 20:33:17 +0100 From: Matthew Wilcox To: Yu Zhao Cc: Ryan Roberts , Andrew Morton , "Kirill A. Shutemov" , Yin Fengwei , David Hildenbrand , Catalin Marinas , Will Deacon , Anshuman Khandual , Yang Shi , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 3/5] mm: Default implementation of arch_wants_pte_order() Message-ID: References: <20230703135330.1865927-1-ryan.roberts@arm.com> <20230703135330.1865927-4-ryan.roberts@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 43BA68000B X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: i35nfnbxwu61u1cxu4itqyyp5kadqfyj X-HE-Tag: 1688672017-256281 X-HE-Meta: U2FsdGVkX184SdMl6Ms74SS4ezHTSzZ7+OySK/hRc0ecDpOb1/aoKnzDlLFcLrZivfpXqOvniBCr7cOtLnMCBz3+lItAmgfMg+310pCyDB7IRBlD/nYWCR6lGlhmUhJndg10zfl5axI5DaeAG9ACGKYgdWzbn6wdjBCBln1klNGbjNwMFht/zSd423g6+euqXGwpTV5JdaBE1d5UhvRPJK2msWeACPu1ZKFUFLSFNL7I96GzB4LT6JiePV8a3DEwVECc0849KBY/oVCY2dRWkR0Gy7tS7TdLYkqQlZQADeABisS3penywaqGtV3V2nwVuy8KxPPrCEXSB7Rr2XOY4Ia/DVDmte3FjGPUMdHpanRmdaJVaJONf1lmvVmJ6yaI8XkYgoQSRwzjfdM+k05+eUdflgQmaIqJMx7o3py299SZx3YDjIY+KhjRPT6TNOYjJlWP4gPervgh3DeZsYIZbcKbeI6odiqBscL1537yYeB6W3fG3xhTugqHML6Roc6vFblOGE8J+mySo57yG61Kn90CSa9xSKgIOcGzWKEqJ0V1lIja5s+ryAg6MAMTSYvQ2IymYMhcF3qxCRWhoF+SOMbl9D7t6VcljRdG+AAeqHEp6sjjWPf/vHx9Lx4DKk1rZuXGXZKJvJMirEjLa4gGXrLr9mDbr8IX6hg7WmGTkhEBiJ0F7O0+2aul8yEn5El6/Bc/AhL+zcsq5FLzg5fjIppSuRs8Y094Dt7N1fXIjp5ViJmTiX7XVbr2yTYvyr6eqGbAlEXVes4wrr1zXpp35Ghcro1cSSkPS8px6yD4hnKVq3fVa7dV1UqLh7KZdwPttOlxbpm9eAp+wjQKmBj1e9sCziIpk2nfIj51C58UcPxlw/4XvUoPLz62aFqbQc03+1dIzK9b3I0R/mvxUsyaLokVkqk5UqfxOXedfL/Wf2oztPgtiZG+Y16k1d1QnutIoXXWNiepdxflreJ7SU5 ShNTfC0Q +tdLhplSQi2tf6ppwOkiUtNsjATx2sOdaPMStiP95Ht8fudW+y34BdeB3mjpqLTQ6omzphsPjVK7+b38Q7xEGz0svNr08HUza5jAUc197R+TXZKsK195HN6hBk6VebN8uvTbEQ5Hg9BgLDXym3THdXOCk8laE7qqvZDc1UqYLYibjZim+BdceJq3bbA== 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 Tue, Jul 04, 2023 at 08:07:19PM -0600, Yu Zhao wrote: > > - On arm64 when the process has marked the VMA for THP (or when > > transparent_hugepage=always) but the VMA does not meet the requirements for a > > PMD-sized mapping (or we failed to allocate, ...) then I'd like to map using > > contpte. For 4K base pages this is 64K (order-4), for 16K this is 2M (order-7) > > and for 64K this is 2M (order-5). The 64K base page case is very important since > > the PMD size for that base page is 512MB which is almost impossible to allocate > > in practice. > > Which case (server or client) are you focusing on here? For our client > devices, I can confidently say that 64KB has to be after 16KB, if it > happens at all. For servers in general, I don't know of any major > memory-intensive workloads that are not THP-aware, i.e., I don't think > "VMA does not meet the requirements" is a concern. It sounds like you've done some measurements, and I'd like to understand those a bit better. There are a number of factors involved: - A larger page size shrinks the length of the LRU list, so systems which see heavy LRU lock contention benefit more - A larger page size has more internal fragmentation, so we run out of memory and have to do reclaim more often (and maybe workload which used to fit in DRAM now do not) (probably others; i'm not at 100% right now) I think concerns about "allocating lots of order-2 folios makes it harder to allocate order-4 folios" are _probably_ not warranted (without data to prove otherwise). All anonymous memory is movable, so our compaction code should be able to create larger order folios.