Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Date:   Tue, 19 Sep 2023 15:56:24 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Vlastimil Babka <vbabka@suse.cz>
CC:     David Rientjes <rientjes@google.com>,
        Christoph Lameter <cl@linux.com>,
        Hyeonggon Yoo <42.hyeyoo@gmail.com>,
        Jay Patel <jaypatel@linux.ibm.com>,
        Roman Gushchin <roman.gushchin@linux.dev>,
        Pekka Enberg <penberg@kernel.org>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "patches@lists.linux.dev" <patches@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] mm/slub: simplify the last resort slab order
 calculation
Message-ID: <ZQlUKJXKYYY5fxL4@feng-clx>
References: <20230908145302.30320-6-vbabka@suse.cz>
 <20230908145302.30320-7-vbabka@suse.cz>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230908145302.30320-7-vbabka@suse.cz>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HXbEkI/AkjB9NQwRl8j9ur93tZDeAWr1qTUklAZ053bZk0c+BnTsK9jGaSDa?=
 =?us-ascii?Q?4o++OOvp3zyeYrVoiEAn8m76bv8cyh4TcePOYiCs+EVYRCNnvmAkXoEpPugg?=
 =?us-ascii?Q?iUvd2bG7X7sbokWKmHdq6PiSrCRSrhC3l3KECg1lhsFgle1Z1tvv6a7tMWbg?=
 =?us-ascii?Q?egNnjXYYP+dgIXRpTujOzMvFznY5OiCWcWN11zwUZRYjbIEE2n3oHUxqgWus?=
 =?us-ascii?Q?l6x7q2Q7h56FnWHxm6176s6RzWCCEhgYFQAu0YEOs3iGeJPqz43vkGGUncnp?=
 =?us-ascii?Q?nMGNwpaRKTiuib8gFQxy8dgy/CC9JmR9T/o5NeBezVk9jRfo2yz4ByDBM6Zt?=
 =?us-ascii?Q?IuiRp5LbiN7HCzdJbcgazBZ5PDIegfbWlHJx5l4mBrczy5r2cRexoFxRl65r?=
 =?us-ascii?Q?35H7hCQ3tu0VTe26EFsnL2LVZs5qp+F2pNXWamZxbWgyBCnuCt3hAN8sb/9S?=
 =?us-ascii?Q?fG0/6UJk+N3XD7LPux9G2qXPOdmKFYEpzFAhKiu4pYCtr81NZUZC8WS7Mr3y?=
 =?us-ascii?Q?v3nTM1A1Pesu6nezQ4TcqhxOpA3Y//Cw9tLjh+sttnjCO7nfmNrMgo77u+Dc?=
 =?us-ascii?Q?yMaJ2oprQxlGwfhGRGH3PU1umgDpSap6in5JGfCuOFncUHZaDggjdnv8c1zV?=
 =?us-ascii?Q?0Y5IV/QZgifAYBco8mF9xnGO3RPr17BfL0FWt3uOq8D5ll4aiV6LoQa09L7z?=
 =?us-ascii?Q?M4YHZPpr2z87wB2IVvLZwNwujIE3pbE2bOhYvorAt3NjDBjTlluUBNYqG/oW?=
 =?us-ascii?Q?GIKtxP32pXugi+Uju4jtCKMWfxLrZ7FcXtLeJRgt4ZnjQWxcHzIdGCF4qEaf?=
 =?us-ascii?Q?iIju1Bc88bkQkFDPZXTtkqAzgB6tDmbg2a/JA/4yVEwTzcB9Sme3uXkftRa8?=
 =?us-ascii?Q?42/qxob/Hm99P/iJJ79PyPal7WlZFjo89eLIoEQEKIpLrnOFILiQjdndUgh8?=
 =?us-ascii?Q?ZFRvW6ucXHu3T+eiguWQ1Q//rAhg9BoOFXL/hb3+6v3Wx1uFJm89gd3M4Ddj?=
 =?us-ascii?Q?rAYyeJDs9N3b5LQSEkhxhfNwsWhdv4MgnfrK/HqSp2qtphvY8VVSJotGouGB?=
 =?us-ascii?Q?jRsISNt7/dGIO7cd17vwXpsSF+vZJrOFyQlGrMZ83l4bvLx7bZDEy6tOv7OU?=
 =?us-ascii?Q?6QapCHmPSC6DtjyZxTfHMXyjoCm/kBJRCrWJTRa70gEUQC185XCgCAi6y3Yl?=
 =?us-ascii?Q?ECigmPaQL8mVvOmRbB49oSdHLCpmBsc5c0CWMN8R0wsaJFy4tsqAC2k0OG0O?=
 =?us-ascii?Q?jMmwiq9KTendhAOLamPF2Tf6yBOICj5dT4/Q6sG0uCSlu6GaTCIL2apqsjnC?=
 =?us-ascii?Q?7lBfXR/P1sfo/Mta6EtPdL/LuyTbuuu3pZxrzG/aQ+wzQ0fhVUCdb/xROvnX?=
 =?us-ascii?Q?Cas5468UQGoteqmFOCUR5F0QJSGF93tdNnPHn/RndtyuOTRDILFw8W8g/V6H?=
 =?us-ascii?Q?XvcyOptZSZkYYH0SX/F2nLJ70vXCgyqt1XvcoOyDj8md89IhpqUwLRbcU1pR?=
 =?us-ascii?Q?y9cHvd8aaEHT9QEmpuhyGn94h22jwOfr0K3mafKQ66uWcdgz0S5V3QcsQ0c8?=
 =?us-ascii?Q?Nu+URlS6qsclurmpbS1MkIk4c7B5Zqm5bk5nCB2g?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 273ec09c-af3c-45c2-743a-08dbb8e73e3b
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2023 08:05:52.8019
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: b64QL5ja+7SdWlaeYXQVQGsdWrRIQL+31IrPyaiUnvq3BgcI5GpCd8jiBhAfet7uH1lgsDlJHxKCpzuJp/vUcQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6401
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE 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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 19 Sep 2023 01:06:11 -0700 (PDT)

Hi Vlastimil,

On Fri, Sep 08, 2023 at 10:53:04PM +0800, Vlastimil Babka wrote:
> If calculate_order() can't fit even a single large object within
> slub_max_order, it will try using the smallest necessary order that may
> exceed slub_max_order but not MAX_ORDER.
> 
> Currently this is done with a call to calc_slab_order() which is
> unecessary. We can simply use get_order(size). No functional change.
> 
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
>  mm/slub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index f7940048138c..c6e694cb17b9 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4193,7 +4193,7 @@ static inline int calculate_order(unsigned int size)
>  	/*
>  	 * Doh this slab cannot be placed using slub_max_order.
>  	 */
> -	order = calc_slab_order(size, 1, MAX_ORDER, 1);
> +	order = get_order(size);


This patchset is a nice cleanup, and my previous test all looked fine. 
And one 'slub_min_order' setup reminded by Christopher [1] doesn't
work as not taking affect with this 1/4 patch.

The root cause seems to be, in current kernel, the 'slub_max_order'
is not ajusted  accordingly with 'slub_min_order', so there is case
that 'slub_min_order' is bigger than the default 'slub_max_order' (3).

And it could be fixed by the below patch 

diff --git a/mm/slub.c b/mm/slub.c
index 1c91f72c7239..dbe950783105 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4702,6 +4702,9 @@ static int __init setup_slub_min_order(char *str)
 {
 	get_option(&str, (int *)&slub_min_order);
 
+	if (slub_min_order > slub_max_order)
+		slub_max_order = slub_min_order;
+
 	return 1;
 }

Though the formal fix may also need to cover case like this kind of
crazy setting "slub_min_order=6 slub_max_order=5" 

[1]. https://lore.kernel.org/lkml/21a0ba8b-bf05-0799-7c78-2a35f8c8d52a@os.amperecomputing.com/

Thanks,
Feng

>  	if (order <= MAX_ORDER)
>  		return order;
>  	return -ENOSYS;
> -- 
> 2.42.0
> 
>