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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 9D078C433DB for ; Wed, 20 Jan 2021 17:36:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4A45C23136 for ; Wed, 20 Jan 2021 17:36:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A45C23136 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8CD046B0010; Wed, 20 Jan 2021 12:36:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 87C7F6B0012; Wed, 20 Jan 2021 12:36:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D0E76B0022; Wed, 20 Jan 2021 12:36:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0234.hostedemail.com [216.40.44.234]) by kanga.kvack.org (Postfix) with ESMTP id 5255D6B0010 for ; Wed, 20 Jan 2021 12:36:45 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 11BB733CD for ; Wed, 20 Jan 2021 17:36:45 +0000 (UTC) X-FDA: 77726858370.02.edge94_25153d92755c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id E28C310097AA1 for ; Wed, 20 Jan 2021 17:36:44 +0000 (UTC) X-HE-Tag: edge94_25153d92755c X-Filterd-Recvd-Size: 8512 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Wed, 20 Jan 2021 17:36:44 +0000 (UTC) Received: by mail-lf1-f46.google.com with SMTP id v67so35223577lfa.0 for ; Wed, 20 Jan 2021 09:36:44 -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=YaiePnQY+bs5Y3022o4Z3Zarrb82Su2xJPiMkpIuFPA=; b=D+0mwpd/VUnW/R6OcVdoKZrl4YIa6nc2g+bxfzzahCNSOIVQ2h0ooR4ZB+P0Cif547 mzrKPNcBqCdKr4B/1cfG11U/Gkz5Li5ARkwCdfV86NRnecNyFgvRACGsU+lj8/Hn1h+e IICkU2S7Fq3ZNccQCDDwpVpQW5EbRfYvDvzu41HQIm4ooWny2UQdEKMuoZh1WTuB0AZ4 hKl58ipVUpX55hEkcLFzBCFr1KVAteln5suPCcB/A8k2nmqQJ56SAYOqj45o2qpiDlYV xc84B4Cem4RznEY5APAJ07U+ffh57jXg8q2gr2I+jF3T2RhceAWVknqR53dPoFHWcr8h lhTQ== 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=YaiePnQY+bs5Y3022o4Z3Zarrb82Su2xJPiMkpIuFPA=; b=UqYwO2fh5UPXycsYaxaUBHUvdYqX5ijEP+CCryuQwfjplFewbdvrlpLcZNlOyfiTdd Dwc8Wyi3r55IPAcE/1xjRYFWsRDT7hojolTEIoKary6o1Zm3wRti8JLhWZDMNeuNT5El rXCP/snxu9OQ2R3UXLxyOJKpQqUb5qnOMVt5DREnp+FC+AZX6gXX6/mbiTZ++3QnogeG DYW8dLB7X7pdwJVBobCoya0eVdjcFZwZjJaUflUik5dpioyS/iRDJjw8IGtZ2BpEpoM4 7+Zx8rgtN4KSOpkNBSZhFK/nEI3GONQIR5ctgekSIfTUiLhi89JUHeM8IMB3t9JHkqwp lPbg== X-Gm-Message-State: AOAM5302ghIT5Ckgxsu8LKOeq/4o+se8jRREFvn7qwQfDPdjsAH/wAP/ UrxN9Ns2o3IJY1gEC4vD0K+TrKvK5tYMcPfDCPLMkA== X-Google-Smtp-Source: ABdhPJxCVR/wWmgKAdo1oGCHDZboYVXHR5SqsujaYHMOMGujZL2oWtndtbkbia4ansbYjHZPtCedx8PnG2ZNaRCrado= X-Received: by 2002:ac2:5442:: with SMTP id d2mr4701758lfn.154.1611164202587; Wed, 20 Jan 2021 09:36:42 -0800 (PST) MIME-Version: 1.0 References: <20201118082759.1413056-1-bharata@linux.ibm.com> In-Reply-To: <20201118082759.1413056-1-bharata@linux.ibm.com> From: Vincent Guittot Date: Wed, 20 Jan 2021 18:36:31 +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: linux-kernel , linux-mm@kvack.org, Christoph Lameter , David Rientjes , Joonsoo Kim , Andrew Morton , guro@fb.com, vbabka@suse.cz, shakeelb@google.com, Johannes Weiner , aneesh.kumar@linux.ibm.com Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, On Wed, 18 Nov 2020 at 09:28, Bharata B Rao wrote: > > The page order of the slab that gets chosen for a given slab > cache depends on the number of objects that can be fit in the > slab while meeting other requirements. We start with a value > of minimum objects based on nr_cpu_ids that is driven by > possible number of CPUs and hence could be higher than the > actual number of CPUs present in the system. This leads to > calculate_order() chosing a page order that is on the higher > side leading to increased slab memory consumption on systems > that have bigger page sizes. > > Hence rely on the number of online CPUs when determining the > mininum objects, thereby increasing the chances of chosing > a lower conservative page order for the slab. > > Signed-off-by: Bharata B Rao > --- > This is a generic change and I am unsure how it would affect > other archs, but as a start, here are some numbers from > PowerPC pseries KVM guest with and without this patch: > > This table shows how this change has affected some of the slab > caches. > =================================================================== > Current Patched > Cache > =================================================================== > TCPv6 53 2 26 1 > net_namespace 53 4 26 2 > dtl 32 2 16 1 > names_cache 32 2 16 1 > task_struct 53 8 13 2 > thread_stack 32 8 8 2 > pgtable-2^11 16 8 8 4 > pgtable-2^8 32 2 16 1 > kmalloc-32k 16 8 8 4 > kmalloc-16k 32 8 8 2 > kmalloc-8k 32 4 8 1 > kmalloc-4k 32 2 16 1 > =================================================================== > > Slab memory (kB) consumption comparision > ================================================================== > Current Patched > ================================================================== > After-boot 205760 156096 > During-hackbench 629145 506752 (Avg of 5 runs) > After-hackbench 474176 331840 (after drop_caches) > ================================================================== > > Hackbench Time (Avg of 5 runs) > (hackbench -s 1024 -l 200 -g 200 -f 25 -P) > ========================================== > Current Patched > ========================================== > 10.990 11.010 > ========================================== > > Measuring the effect due to CPU hotplug > ---------------------------------------- > Since the patch doesn't consider all the possible CPUs for page > order calcluation, let's see how affects the case when CPUs are > hotplugged. Here I compare a system that is booted with 64CPUs > with a system that is booted with 16CPUs but hotplugged with > 48CPUs after boot. These numbers are with the patch applied. > > Slab memory (kB) consumption comparision > =================================================================== > 64bootCPUs 16bootCPUs+48HotPluggedCPUs > =================================================================== > After-boot 390272 159744 > After-hotplug - 251328 > During-hackbench 1001267 941926 (Avg of 5 runs) > After-hackbench 913600 827200 (after drop_caches) > =================================================================== > > Hackbench Time (Avg of 5 runs) > (hackbench -s 1024 -l 200 -g 200 -f 25 -P) > =========================================== > 64bootCPUs 16bootCPUs+48HotPluggedCPUs > =========================================== > 12.554 12.589 > =========================================== > mm/slub.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > I'm facing significant performances regression on a large arm64 server system (224 CPUs). Regressions is also present on small arm64 system (8 CPUs) but in a far smaller order of magnitude On 224 CPUs system : 9 iterations of hackbench -l 16000 -g 16 v5.11-rc4 : 9.135sec (+/- 0.45%) v5.11-rc4 + revert this patch: 3.173sec (+/- 0.48%) v5.10: 3.136sec (+/- 0.40%) This is a 191% regression compared to v5.10. 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%) > diff --git a/mm/slub.c b/mm/slub.c > index 34dcc09e2ec9..8342c0a167b2 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -3433,7 +3433,7 @@ static inline int calculate_order(unsigned int size) > */ > min_objects = slub_min_objects; > if (!min_objects) > - min_objects = 4 * (fls(nr_cpu_ids) + 1); > + min_objects = 4 * (fls(num_online_cpus()) + 1); > max_objects = order_objects(slub_max_order, size); > min_objects = min(min_objects, max_objects); > > -- > 2.26.2 >