Message ID | 20230315113133.11326-2-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp2273177wrd; Wed, 15 Mar 2023 04:33:54 -0700 (PDT) X-Google-Smtp-Source: AK7set8eVIVAXshYGzscE4jB8DfdX187+2NmB7Byop+socHonOKV7ASM46LhM3OSQd8u6FF0t4IZ X-Received: by 2002:a05:6870:561f:b0:177:afdd:b49 with SMTP id m31-20020a056870561f00b00177afdd0b49mr7546535oao.48.1678880033891; Wed, 15 Mar 2023 04:33:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678880033; cv=none; d=google.com; s=arc-20160816; b=Cyf084VttR3l7jIOzsgjH6EO7hmo0iqtRhwieE7/hbi9RHYOwLsxBvcBnb/IyzMged TVKnidPAW0zmz8NB7QxV86tzQtzLaOwodH92swO/so7p8XAp9uBnaR7ipLMaMa5gm1e+ Ss+Xe1flid6ITYrDZjQe5L0wzaemrzrdpiU6Xtc8jPwh0AAsTzrcv3G7/xNhaiGUzh/+ 7ezGxiGhrYWhVbfgNbWcK5/xqksYaFpaWFHO9GDQ+8+27KKj3KP47QHsBLWmGvKmnyuB fwYnOAhj+5gXkO3RhnQuADrorR5GSy66FFOlEGqEeYejHU8Fh2Wf7TfwJWvmaCXFk83v ZJPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ojvIeEkFwkjIxhoLZbBitZpqyYtExVBxUpzX5dqiNDc=; b=Uo/Ux9fnhmuraj72XpzbbUJKi53p+WaFT8Z+YwX0a9pbuILRx3i6rWQquL+FSXaJr4 rwYeKIM7494WaCSKETZjJywylrXRIiApIedh1zuFc/HAuxYS5NyNfeWjBrOMvkXy8Nz6 GBQEnWjz3fkJ+GrbgAdkVNO/fAHE4PByyydT9baG9aX41nStq/33bDrpbdrBPlU28Ida 1GoupRFbD+ODX7OUU2EkALEAUjqYsNyL8Phevq53Xe16j8s2naIBd39h8y7WrKiCuTd8 0HMToMsWuby5UAvUdGRSWvcMGrZ7OiszH+A5FDCjyu0oQr1B4xuybhjktNMOpvmIuXtq Q3XQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="h/GNn2Qn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l5-20020a544105000000b0037d8cdbc1f5si4155445oic.138.2023.03.15.04.33.40; Wed, 15 Mar 2023 04:33:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="h/GNn2Qn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231636AbjCOLbw (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others); Wed, 15 Mar 2023 07:31:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231506AbjCOLbo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 15 Mar 2023 07:31:44 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D2E6637F7; Wed, 15 Mar 2023 04:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678879903; x=1710415903; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=AX8fQ9JFCUx8sgKM3jU0DHxltPa90kVlWb8uT8+Z308=; b=h/GNn2Qn4BExyno6TU2mepAnbByIuOLSFyB/0bB0ZJZXY8rNcci6lGee mBcrT5lJ+BuenVwMzYJSbLsXLOpSX/lTpilqM6aGnfGxawNHe27izFw8o fDsCobLXkoLTgIBqGokhTxI5Zy1YE5bIR/7adF2nqAz81p8Vb6DkpMpRs ERjheg5H3U/O3Ukc4XKpl6msC1m132AWiaZYnFcGkFeuSNZGMS7h+z85/ Af2Eyj6NqusuyyxEH60gpbqo6xjmALSSne3/PSlaWLqiX4hTIizNmNY9X d8wLI2Pttir7Q4yXOeZN5coAprh20WiWTJXDQRnRvV2D0Dl3Jvyv/bdjG Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="317330278" X-IronPort-AV: E=Sophos;i="5.98,262,1673942400"; d="scan'208";a="317330278" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2023 04:31:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="925310513" X-IronPort-AV: E=Sophos;i="5.98,262,1673942400"; d="scan'208";a="925310513" Received: from nopopovi-mobl1.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.33.48]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2023 04:31:38 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id AB8FF10CC9D; Wed, 15 Mar 2023 14:31:35 +0300 (+03) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>, David Hildenbrand <david@redhat.com> Cc: linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, sparclinux@vger.kernel.org, David Miller <davem@davemloft.net> Subject: [PATCH 01/10] sparc/mm: Fix MAX_ORDER usage in tsb_grow() Date: Wed, 15 Mar 2023 14:31:24 +0300 Message-Id: <20230315113133.11326-2-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230315113133.11326-1-kirill.shutemov@linux.intel.com> References: <20230315113133.11326-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760433310737736171?= X-GMAIL-MSGID: =?utf-8?q?1760433310737736171?= |
Series |
Fix confusion around MAX_ORDER
|
|
Commit Message
Kirill A. Shutemov
March 15, 2023, 11:31 a.m. UTC
MAX_ORDER is not inclusive: the maximum allocation order buddy allocator
can deliver is MAX_ORDER-1.
Fix MAX_ORDER usage in tsb_grow().
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: sparclinux@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
---
arch/sparc/mm/tsb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On 03/15/23 14:31, Kirill A. Shutemov wrote: > MAX_ORDER is not inclusive: the maximum allocation order buddy allocator > can deliver is MAX_ORDER-1. > > Fix MAX_ORDER usage in tsb_grow(). > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Cc: sparclinux@vger.kernel.org > Cc: David Miller <davem@davemloft.net> > --- > arch/sparc/mm/tsb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/sparc/mm/tsb.c b/arch/sparc/mm/tsb.c > index 912205787161..dba8dffe2113 100644 > --- a/arch/sparc/mm/tsb.c > +++ b/arch/sparc/mm/tsb.c > @@ -402,8 +402,8 @@ void tsb_grow(struct mm_struct *mm, unsigned long tsb_index, unsigned long rss) > unsigned long new_rss_limit; > gfp_t gfp_flags; > > - if (max_tsb_size > (PAGE_SIZE << MAX_ORDER)) > - max_tsb_size = (PAGE_SIZE << MAX_ORDER); > + if (max_tsb_size > (PAGE_SIZE << (MAX_ORDER - 1))) > + max_tsb_size = (PAGE_SIZE << (MAX_ORDER - 1)); > > new_cache_index = 0; > for (new_size = 8192; new_size < max_tsb_size; new_size <<= 1UL) { > Fortunately, I think this only comes into play if MAX_ORDER <= 7. Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
On Wed, Mar 15, 2023 at 02:31:24PM +0300, Kirill A. Shutemov wrote: > MAX_ORDER is not inclusive: the maximum allocation order buddy allocator > can deliver is MAX_ORDER-1. > > Fix MAX_ORDER usage in tsb_grow(). > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Cc: sparclinux@vger.kernel.org > Cc: David Miller <davem@davemloft.net> Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> > --- > arch/sparc/mm/tsb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/sparc/mm/tsb.c b/arch/sparc/mm/tsb.c > index 912205787161..dba8dffe2113 100644 > --- a/arch/sparc/mm/tsb.c > +++ b/arch/sparc/mm/tsb.c > @@ -402,8 +402,8 @@ void tsb_grow(struct mm_struct *mm, unsigned long tsb_index, unsigned long rss) > unsigned long new_rss_limit; > gfp_t gfp_flags; > > - if (max_tsb_size > (PAGE_SIZE << MAX_ORDER)) > - max_tsb_size = (PAGE_SIZE << MAX_ORDER); > + if (max_tsb_size > (PAGE_SIZE << (MAX_ORDER - 1))) > + max_tsb_size = (PAGE_SIZE << (MAX_ORDER - 1)); > > new_cache_index = 0; > for (new_size = 8192; new_size < max_tsb_size; new_size <<= 1UL) { > -- > 2.39.2 >
On Wed, Mar 15, 2023 at 08:04:37PM -0700, Mike Kravetz wrote: > On 03/15/23 14:31, Kirill A. Shutemov wrote: > > MAX_ORDER is not inclusive: the maximum allocation order buddy allocator > > can deliver is MAX_ORDER-1. > > > > Fix MAX_ORDER usage in tsb_grow(). > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > Cc: sparclinux@vger.kernel.org > > Cc: David Miller <davem@davemloft.net> > > --- > > arch/sparc/mm/tsb.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/sparc/mm/tsb.c b/arch/sparc/mm/tsb.c > > index 912205787161..dba8dffe2113 100644 > > --- a/arch/sparc/mm/tsb.c > > +++ b/arch/sparc/mm/tsb.c > > @@ -402,8 +402,8 @@ void tsb_grow(struct mm_struct *mm, unsigned long tsb_index, unsigned long rss) > > unsigned long new_rss_limit; > > gfp_t gfp_flags; > > > > - if (max_tsb_size > (PAGE_SIZE << MAX_ORDER)) > > - max_tsb_size = (PAGE_SIZE << MAX_ORDER); > > + if (max_tsb_size > (PAGE_SIZE << (MAX_ORDER - 1))) > > + max_tsb_size = (PAGE_SIZE << (MAX_ORDER - 1)); > > > > new_cache_index = 0; > > for (new_size = 8192; new_size < max_tsb_size; new_size <<= 1UL) { > > > > Fortunately, I think this only comes into play if MAX_ORDER <= 7. I think it's unlikely that such low ARCH_FORCE_MAX_ORDER is ever used. Judging by c88c545bf320 ("sparc64: Add FORCE_MAX_ZONEORDER and default to 13") log the option to override MAX_ORDER was added to "request large (32M) contiguous memory during boot for creating IOTSB backing store", so it was about to increase MAX_ORDER. Generally, we may restrict sparc::ARCH_FORCE_MAX_ORDER to be above 7 and drop this check entirely > Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com> > -- > Mike Kravetz >
On 3/15/23 12:31, Kirill A. Shutemov wrote: > MAX_ORDER is not inclusive: the maximum allocation order buddy allocator > can deliver is MAX_ORDER-1. > > Fix MAX_ORDER usage in tsb_grow(). > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> > Cc: sparclinux@vger.kernel.org > Cc: David Miller <davem@davemloft.net> > --- > arch/sparc/mm/tsb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/sparc/mm/tsb.c b/arch/sparc/mm/tsb.c > index 912205787161..dba8dffe2113 100644 > --- a/arch/sparc/mm/tsb.c > +++ b/arch/sparc/mm/tsb.c > @@ -402,8 +402,8 @@ void tsb_grow(struct mm_struct *mm, unsigned long tsb_index, unsigned long rss) > unsigned long new_rss_limit; > gfp_t gfp_flags; > > - if (max_tsb_size > (PAGE_SIZE << MAX_ORDER)) > - max_tsb_size = (PAGE_SIZE << MAX_ORDER); > + if (max_tsb_size > (PAGE_SIZE << (MAX_ORDER - 1))) > + max_tsb_size = (PAGE_SIZE << (MAX_ORDER - 1)); > > new_cache_index = 0; > for (new_size = 8192; new_size < max_tsb_size; new_size <<= 1UL) {
diff --git a/arch/sparc/mm/tsb.c b/arch/sparc/mm/tsb.c index 912205787161..dba8dffe2113 100644 --- a/arch/sparc/mm/tsb.c +++ b/arch/sparc/mm/tsb.c @@ -402,8 +402,8 @@ void tsb_grow(struct mm_struct *mm, unsigned long tsb_index, unsigned long rss) unsigned long new_rss_limit; gfp_t gfp_flags; - if (max_tsb_size > (PAGE_SIZE << MAX_ORDER)) - max_tsb_size = (PAGE_SIZE << MAX_ORDER); + if (max_tsb_size > (PAGE_SIZE << (MAX_ORDER - 1))) + max_tsb_size = (PAGE_SIZE << (MAX_ORDER - 1)); new_cache_index = 0; for (new_size = 8192; new_size < max_tsb_size; new_size <<= 1UL) {