From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by sourceware.org (Postfix) with ESMTPS id 5B8503857347 for ; Wed, 29 Jun 2022 02:37:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5B8503857347 Received: from canpemm500005.china.huawei.com (unknown [172.30.72.53]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4LXlvs2nWrz9sxb; Wed, 29 Jun 2022 10:36:25 +0800 (CST) Received: from [10.174.176.57] (10.174.176.57) by canpemm500005.china.huawei.com (7.192.104.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 29 Jun 2022 10:37:05 +0800 Subject: =?UTF-8?B?UmU6IOi9rOWPkTogbWFsbG9jOiBPcHRpbWl6ZSB0aGUgbnVtYmVyIG9m?= =?UTF-8?Q?_arenas_for_better_application_performance?= To: Adhemerval Zanella , DJ Delorie , Yang Yanchao References: <1a8f10e034e7489c8e9f090e9c90b396@huawei.com> CC: , "libc-alpha@sourceware.org" , , , , Qingqing Li From: Qingqing Li Message-ID: <4f855db3-d4d5-eb0a-0edf-b7e2a61d6a78@huawei.com> Date: Wed, 29 Jun 2022 10:37:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <1a8f10e034e7489c8e9f090e9c90b396@huawei.com> Content-Type: text/plain; charset="gbk" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.176.57] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500005.china.huawei.com (7.192.104.229) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, MIME_CHARSET_FARAWAY, NICE_REPLY_A, 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: Wed, 29 Jun 2022 02:37:11 -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. > Agreed, the variable narenas_limit just Initialize once, if there has a scenario that we dynamic adjust the cpu affnity, __get_nprocs_sched is not a good choice. my opinion first use __get_nprocs as a static valule(the old default behavior), and user use glibc.TUNABLE to adjust arana number. Also, we can do more research and test to optimize the default arena number.