Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp95060pxb; Thu, 21 Jan 2021 02:07:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJxb68I7gyeJxlROFXH+ExD/Q7HgjBC2Zm+OEJcoWOtv9f1YkVnqCGpcNr0I1GXqNd7/M9ss X-Received: by 2002:a17:906:1958:: with SMTP id b24mr8570859eje.263.1611223631745; Thu, 21 Jan 2021 02:07:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611223631; cv=none; d=google.com; s=arc-20160816; b=R9HY4D+uXFDduwN73nzw9kBgSE4QtJfWVWHFP4TSBkMLs7hoaf+G7zpi2azebd8iph m3wKywBnOblbP9ALp/U2CfZ+u+1fvW1kRQ3o0mOV32MddROolmgID8HguUDW5GTfY5F+ qD3L2ydEqEENHv8jyN2ktPaYKW+kJowhfAuJpkK7ZfkvKGG45iE3nHJvqqRPs3DpEFr/ BkR6GB74JqR0NAGqHgLy2yaqblmTy7Szew4oRM0c+FoKX64icD3OoDF0sTpXlnkKssMf 2ckodL9QEka5KTPNghNF0RZbY0ms7QpbRR3ArKu4x2gvb9SB5ZME3GqzQtqEuvUbL+3j trig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=bkHkydUKlpj/KuLVjow7UXhsTremVY27asI1/Qhta6k=; b=GN1IXH7BVZoBxLwlaxr8EhMvDng+cc9Rh1vG0JGkyYEBQ5nYLH7ncOsjWzPXRJHWw1 qIpPwr20bX6Fc44BMLZ2qy294QT/iS6Oe0qx39jzsB/idYzS4546R09vfweYFKnNhbty 5Ew3qrYXuimqoFL8ox2kB2IEtkw1K4Jm/tnVr7n6WsarGxwvRV5EsCexNczcLNdBLk3g Dp01DDOyLDuWQp/BoU2sB0IaPThEt9TnqMRc7ZekAJyQjIdVooqBMzLV5KTXAIjNZekf ugACX8pXgDEfNkOfwsKUjwHRaoKDOrUxQJDKYofZHWflBYhAhQVUJ0T+OUr45nOEzrNV ji3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k5si1609386ejj.483.2021.01.21.02.06.46; Thu, 21 Jan 2021 02:07:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729091AbhAUKDW (ORCPT + 99 others); Thu, 21 Jan 2021 05:03:22 -0500 Received: from gentwo.org ([3.19.106.255]:52768 "EHLO gentwo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728469AbhAUKCp (ORCPT ); Thu, 21 Jan 2021 05:02:45 -0500 Received: by gentwo.org (Postfix, from userid 1002) id 5E6563F04E; Thu, 21 Jan 2021 10:01:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 5C1C43EFF6; Thu, 21 Jan 2021 10:01:57 +0000 (UTC) Date: Thu, 21 Jan 2021 10:01:57 +0000 (UTC) From: Christoph Lameter X-X-Sender: cl@www.lameter.com To: Bharata B Rao cc: Vincent Guittot , linux-kernel , linux-mm@kvack.org, David Rientjes , Joonsoo Kim , Andrew Morton , guro@fb.com, vbabka@suse.cz, shakeelb@google.com, Johannes Weiner , aneesh.kumar@linux.ibm.com Subject: Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order In-Reply-To: <20210121053003.GB2587010@in.ibm.com> Message-ID: References: <20201118082759.1413056-1-bharata@linux.ibm.com> <20210121053003.GB2587010@in.ibm.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Jan 2021, Bharata B Rao wrote: > > The problem is that calculate_order() is called a number of times > > before secondaries CPUs are booted and it returns 1 instead of 224. > > This makes the use of num_online_cpus() irrelevant for those cases > > > > After adding in my command line "slub_min_objects=36" which equals to > > 4 * (fls(num_online_cpus()) + 1) with a correct num_online_cpus == 224 > > , the regression diseapears: > > > > 9 iterations of hackbench -l 16000 -g 16: 3.201sec (+/- 0.90%) > > Should we have switched to num_present_cpus() rather than > num_online_cpus()? If so, the below patch should address the > above problem. There is certainly an initcall after secondaries are booted where we could redo the calculate_order? Or the num_online_cpus needs to be up to date earlier. Why does this issue not occur on x86? Does x86 have an up to date num_online_cpus earlier?