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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 96137C77B76 for ; Fri, 14 Apr 2023 13:04:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ExKz1vGRnVpwK+YfqpvJTBpUG9qyIcnnhoB8pCUzkvA=; b=JbKQueoq7f33Kk HBYO811Iwk2+JlurWMqZ5lIozEpGzRhwuG5DKjXgenpG9ER4GTpYV8A8an/hxL2lFkL/XB/09xMNw jsxT0aI8pDvFLhM3wjylLIMG65osOBAD2FwqQ+Tp1vkEw1ZJPrXvN6M93oKpG6OW9k5TybKXrJf9Y ozAC2mK75kpx/5nuhtTYLGmrUErzO7UXrQIOuGx0IFn7tHeANdKc0J46ISJ2N9vySbKdFtlGgLIyu Y8Yqvif+p9kPN4k7myFMcG3evhB+jmiv+AbCo/ko+aqY2ssd91RLS0hIZvAelTIMGscLOODfsa49H S5mVU2MW5FAE47A4CyaA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pnJ5l-009bco-0q; Fri, 14 Apr 2023 13:03:53 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pnJ5M-009bQ5-2U for linux-arm-kernel@lists.infradead.org; Fri, 14 Apr 2023 13:03:37 +0000 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 A585D1758; Fri, 14 Apr 2023 06:04:09 -0700 (PDT) Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com [10.1.196.26]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2CD9F3F6C4; Fri, 14 Apr 2023 06:03:24 -0700 (PDT) From: Ryan Roberts To: Andrew Morton , "Matthew Wilcox (Oracle)" , Yu Zhao , "Yin, Fengwei" Cc: Ryan Roberts , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org Subject: [RFC v2 PATCH 05/17] mm: Routines to determine max anon folio allocation order Date: Fri, 14 Apr 2023 14:02:51 +0100 Message-Id: <20230414130303.2345383-6-ryan.roberts@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230414130303.2345383-1-ryan.roberts@arm.com> References: <20230414130303.2345383-1-ryan.roberts@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230414_060328_932211_7EBA77CC X-CRM114-Status: GOOD ( 10.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 + #endif /* _LINUX_MM_H */ diff --git a/mm/memory.c b/mm/memory.c index ca32f59acef2..d7e34a8c46aa 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3022,6 +3022,14 @@ static struct folio *try_vma_alloc_movable_folio(struct vm_area_struct *vma, return vma_alloc_movable_folio(vma, vaddr, 0, zeroed); } +static inline int max_anon_folio_order(struct vm_area_struct *vma) +{ + /* + * TODO: Policy for maximum folio order should likely be per-vma. + */ + return ANON_FOLIO_ORDER_MAX; +} + /* * Handle write page faults for pages that can be reused in the current vma * -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel