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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73FD4C433DB for ; Thu, 4 Feb 2021 07:34:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3303264F55 for ; Thu, 4 Feb 2021 07:34:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234509AbhBDHdv (ORCPT ); Thu, 4 Feb 2021 02:33:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233173AbhBDHdm (ORCPT ); Thu, 4 Feb 2021 02:33:42 -0500 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7219FC0613D6 for ; Wed, 3 Feb 2021 23:33:01 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id r23so313977ljh.1 for ; Wed, 03 Feb 2021 23:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mVefbxEsGh9zkzfC1oY5DTuWOWgG+z41sRnOeNBLDiE=; b=RMhuOnzSHH/+k63L/smA9k18SLyi9Kn18dVA486qpcwAxQsuyq90SWofxMCQgFoZ0D qNlE1XuYlA2DC80aqDH57A0Knv7eE0i7MPe/DZrTINiltSxKwVdIzUbtKkjYheV6T6V/ LtEVMPpuxm80Zp9K1Lf8Ezm0j5It5U/pq+Qi8asnmNX6aHC0m/yAf5vMBau4rwRAoEMJ r1Vc0xw/eTjc2CxHjHpC05dBvgYX6Q1fwhqsP48Y8RGNoS1pG+rQVeVSx23r7SONcE7G alh3bBAKZhKRuGKp/851XtzD+4EXTEtu95SZYVgxk0xyq9Pl2jb8o8QHLtyZVJKmK8yb aVbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mVefbxEsGh9zkzfC1oY5DTuWOWgG+z41sRnOeNBLDiE=; b=GfvPn26k55yZvNHSWEQZT0HFK64QuxTehZ8ODyTcMXCNFdOR2rOQ7+C4j3PsiZTQaT 5wmHtqEcsx8Q5vyH7fqjAuMbDNx4BjLSCLDuE8rT1LeCMnvYsY9oH9p2+mj/AoNC1wZU mlJ/A7HZOj/K8UwNUvloLW65YJPPoQ9SmXEkLpxwMiB7to027LdRhSjVje4bmvgZGIzy KBU7VE8UiUUe5Qa3xoLK3Na2CRf9QGS7Vz/Zh7zeNmsB4lXizGAjRg22kNLt1lVmb5SA yXqVQuL9d7Z3DM6D32GSVin66EStiy34/IbbWdx9oTCyE6rIXPWi9acWeT9QIHYaiYEB OkEg== X-Gm-Message-State: AOAM532z8vow6FaL4mN4dlYFZiC9ZvL3KkGQe5oslgzQRc3nmfwtJ1li VDGYfJfUhiPqB16Ds/kuQcwR+dinnjikp3DQM+QHbw== X-Google-Smtp-Source: ABdhPJwBLCCqZOi/7mMT+j+lhfXFW008mVnat/YMTxJNMizUpj8H4Ra5Q8eCq4oP0GmSdeRlsTk13BDj5jtxAm31gJw= X-Received: by 2002:a2e:9857:: with SMTP id e23mr3948643ljj.209.1612423979844; Wed, 03 Feb 2021 23:32:59 -0800 (PST) MIME-Version: 1.0 References: <786571e7-b9a2-4cdb-06d5-aa4a4b439b7e@suse.cz> <20210123051607.GC2587010@in.ibm.com> <66652406-25e4-a9e7-45a1-8ad14d2e8a36@suse.cz> <20210126230305.GD30941@willie-the-truck> <81424d71-c479-4c4a-de14-0a9b3f636e23@suse.cz> <20210203111009.GB2869122@in.ibm.com> In-Reply-To: <20210203111009.GB2869122@in.ibm.com> From: Vincent Guittot Date: Thu, 4 Feb 2021 08:32:48 +0100 Message-ID: Subject: Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order To: Bharata B Rao Cc: Vlastimil Babka , Christoph Lameter , Will Deacon , linux-kernel , linux-mm@kvack.org, David Rientjes , Joonsoo Kim , Andrew Morton , guro@fb.com, Shakeel Butt , Johannes Weiner , aneesh.kumar@linux.ibm.com, Jann Horn , Michal Hocko , Catalin Marinas Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Feb 2021 at 12:10, Bharata B Rao wrote: > > On Wed, Jan 27, 2021 at 12:04:01PM +0100, Vlastimil Babka wrote: > > On 1/27/21 10:10 AM, Christoph Lameter wrote: > > > On Tue, 26 Jan 2021, Will Deacon wrote: > > > > > >> > Hm, but booting the secondaries is just a software (kernel) action? They are > > >> > already physically there, so it seems to me as if the cpu_present_mask is not > > >> > populated correctly on arm64, and it's just a mirror of cpu_online_mask? > > >> > > >> I think the present_mask retains CPUs if they are hotplugged off, whereas > > >> the online mask does not. We can't really do any better on arm64, as there's > > >> no way of telling that a CPU is present until we've seen it. > > > > > > The order of each page in a kmem cache --and therefore also the number > > > of objects in a slab page-- can be different because that information is > > > stored in the page struct. > > > > > > Therefore it is possible to retune the order while the cache is in operaton. > > > > Yes, but it's tricky to do the retuning safely, e.g. if freelist randomization > > is enabled, see [1]. > > > > But as a quick fix for the regression, the heuristic idea could work reasonably > > on all architectures? > > - if num_present_cpus() is > 1, trust that it doesn't have the issue such as > > arm64, and use it > > - otherwise use nr_cpu_ids > > > > Long-term we can attempt to do the retuning safe, or decide that number of cpus > > shouldn't determine the order... > > > > [1] https://lore.kernel.org/linux-mm/d7fb9425-9a62-c7b8-604d-5828d7e6b1da@suse.cz/ > > So what is preferrable here now? Above or other quick fix or reverting > the original commit? I'm fine with whatever the solution as long as we can use keep using nr_cpu_ids when other values like num_present_cpus, don't reflect correctly the system Regards, Vincent > > Regards, > Bharata.