From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) by sourceware.org (Postfix) with ESMTPS id 1B9BB38582A3 for ; Tue, 28 Jun 2022 19:17:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B9BB38582A3 Received: by mail-oo1-xc2f.google.com with SMTP id i19-20020a4ad093000000b004256ad0893fso2673163oor.3 for ; Tue, 28 Jun 2022 12:17:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zpsiyq2apzNI8oQdueAvomm2OHK5HwsrWuEzu8/caT8=; b=2cPRsMuhmBkzchhBjoRsP+5itqQGr6grX2kp4OE9wlTIx937wwr9TiyvKMv/Ay9Nvg O6CQaHxJZ4d2vyGhSnuyHUHXDUepMiNoeOwEyE9gCPjuZKo67ZwliNW4Nq/0F03GaRUq eg9pmyI6JzWXbAm3apPXccHEGUnTAp6UORJlg+xWCAkiBimtJdu15DrWsUvJFLQ9e2f/ dTaX2hSjKaKUy/MnigVmhpXzvqqR1VkM5g4P9flza96I8IVVpl5KgQBdeEEaMnNvF6oQ tXMOU+RxOwhksiW5A/zeCnHkpt7jItXu28pOwDPfaIWT9bUkHsWj0Y55eMI/S2ZwXeRO /I+A== X-Gm-Message-State: AJIora+y6jDzu3yU5b6hbN3WcFvmfTyGX7a13KScfdwfGvKNCC4eLLvu Fn1IGsAVBD1xFyNPvYEeU65Zng== X-Google-Smtp-Source: AGRyM1tknu1LTSJILnQK3v6nvc9MnJQeq6fMUUU1EvbNSaHVmvhjLFQHSR5oNXTE9ZebA66xMx/y7g== X-Received: by 2002:a05:6820:1606:b0:41b:c35f:999a with SMTP id bb6-20020a056820160600b0041bc35f999amr9020982oob.43.1656443862384; Tue, 28 Jun 2022 12:17:42 -0700 (PDT) Received: from smtpclient.apple ([2804:431:c7ca:6d95:25db:29b6:be9b:9202]) by smtp.gmail.com with ESMTPSA id o63-20020a4a4442000000b00425806a20f5sm7900588ooa.3.2022.06.28.12.17.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jun 2022 12:17:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: malloc: Optimize the number of arenas for better application performance From: Adhemerval Zanella In-Reply-To: Date: Tue, 28 Jun 2022 16:17:38 -0300 Cc: Yang Yanchao , libc-alpha@sourceware.org, glebfm@altlinux.org, ldv@altlinux.org, carlos@redhat.com, siddhesh@sourceware.org, linfeilong@huawei.com, liqingqing3@huawei.com Content-Transfer-Encoding: 7bit Message-Id: References: To: DJ Delorie X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2022 19:17:46 -0000 > On 28 Jun 2022, at 15:56, DJ Delorie wrote: > > Yang Yanchao writes: >> However, my machine is 96 cores and I have 91 cores bound. > > One benchmark on one uncommon configuration is not sufficient reason to > change a core tunable. What about other platforms? Other benchmarks? > Other percentages of cores scheduled? > > I would reject this patch based solely on the lack of data backing up > your claims. > >> - int n = __get_nprocs_sched (); >> + int n = __get_nprocs (); > > I've heard complaints about how our code leads to hundreds of arenas on > processes scheduled on only two CPUs. I think using the number of > *schedulable* cores makes more sense than using the number of *unusable* > cores. > > I think this change warrants more research. I think this patch make sense mainly because we changed to use the schedulable cores without much though either. Maybe we can revert to previous semantic and investigate that using the schedulable number makes more sense.