Message ID | 20230922092823.478042-1-wyes.karny@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp5881665vqi; Fri, 22 Sep 2023 14:42:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFgp+m9Uta/guqN1/PK+UlZ/1TmvdIN1G+/zmKZXXEjSjF0jAf5mWCe4t/pbct+GaLfFk+1 X-Received: by 2002:a4a:c91a:0:b0:57b:94b7:c6ba with SMTP id v26-20020a4ac91a000000b0057b94b7c6bamr871064ooq.0.1695418971168; Fri, 22 Sep 2023 14:42:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1695418971; cv=pass; d=google.com; s=arc-20160816; b=uD9OCrv5CnepuCHi4HIFYIOZyGXucV4y0d9d/RDkOCmstOzE12YguRRuWSkAU4GjmG O8Hoac3DEHF9wyBLJM1JP+Ymt4VBZFpYaklk7kNyzgzoSzNB7seEr0b79I73WWvwy3hT 81T1htFoXWPBrP3/Z8RefRE9H80aPb8qho6syH8E9HF4i0Dsy9OnUJo63E7f/y7CM7Ao 210Ykbmi1luQFJgvvgkorS9fL/QaePogdcQuWqaiYTTuj9En+kqT1qiEbcbYidtXsNcM qsGCdlVLwhw9el8KRg65Mlwds3sLaSZTUEoleq3yKNypqLbloI84uOP6mVTquSva+ywa NfBA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=6HXVE6751pthjZl8sjFlGMm8tVlHrgSQ9/x3gpD5sOQ=; fh=FZUVGORP7yD1iTyRvakBvNsLpyTK/lRlUGKFlRWfzeE=; b=p3on+wMPzEnPpwHhChAbXuqCmOrH/vxuRSixQHS6kTElrmkZMxEsz/UR3z3UI5hJwP wyUl0t+eb4z/rUsxOaCjKC+ScgO9c+hPYhMSbOybGgkFpyo7bVcIF8ky1mqdJca9z81A m5eVb7n8eDF8ML4+XGUUpmtSzMUB+9gA4934moI0OLFXmEx2S0xAA00LDm6VtSoHeinh mRj8WhiULZC5lYH26d2bp+V1WcbJ6q+/FfWK0Exu72Swl3k9WZz7BZyYXyUcmrnE+E/6 WUoiqRmm/I1LhPW++L3mW/Pxv6wNiGIrmKWGPosgKYPJ5J5NiImxJj7cwWnU6eioa7m2 nk6w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=G2iEq7ll; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id a35-20020a631a63000000b00573feb1e7c6si4421455pgm.888.2023.09.22.14.42.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 14:42:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=G2iEq7ll; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 7E629856B124; Fri, 22 Sep 2023 02:28:46 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232727AbjIVJ2s (ORCPT <rfc822;chrisfriedt@gmail.com> + 30 others); Fri, 22 Sep 2023 05:28:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231157AbjIVJ2r (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 22 Sep 2023 05:28:47 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2050.outbound.protection.outlook.com [40.107.223.50]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0AB06197; Fri, 22 Sep 2023 02:28:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Og7FCtTDN4qn8rG9qOAzhATAIhS+HbH19dMr+E5+eEGIwpbB2oc5qZ1ryPfAN29bJao5HXKgjERQqe8wY4MlRfDw55OF6M1p5GMfBMgrX41X5XliOYJB68UmV8bkaJ7lp/D/4VGaU0zVqopKytm775MMmrHibXuwKou1Ab3QXK39klssMs7ife8rDA39DPT7dvIWhQdNduM17NItPLodH2DrTVeR16QVpgvYtpN1o23ORHDJpTyNNZAiUm9s6ewsF5yeIhOm5mwvBZndxxBCuRsgCOxvduTCpqVozPNF3sLyaalWHF63AmlWvJDBhdNr3ucQoMceolWfDTGnpBd00w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6HXVE6751pthjZl8sjFlGMm8tVlHrgSQ9/x3gpD5sOQ=; b=K5WWJVaD6A0dI9PTAoxJHRNypUqW2EYOvFo4coHbPSJVu/2R0gxkk+kHQYSlFuYWmTIvWL9VcMJi48lt8XdaiRTecUZCVdmTK0fW9M+/3mJkw+iS8yPsXhmCa4hwZZevL+Ycxx6hmbJ/NJOC9QfLRsP9GPrzJloNbEVXb1KIGFPXnxbh6FAtFVIjm5uJ2JNHTkdbQSe39T6hNYbfs49SHBg61iYefneSgrGHgx5G7bzuoMiU+wcmdegjZN1Wf2QqxXkljGlnSvdHT2BRu0/O1K5CjpxUvcH0LUdrAuW2T4KH8L7WUxL1lrzRusd8Cu9DXty04a8Z4d3rAItq6KA7EQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6HXVE6751pthjZl8sjFlGMm8tVlHrgSQ9/x3gpD5sOQ=; b=G2iEq7llvevR8fDJf1VvpwAMTI+AiwxqqAkDKe/r3M1MC78pZ1AYpo4p3SWqcuROfYRkot9tgaCZt04r0vE9KDQE9eJ8a6q3pczbFEEzC+RmKedwB0DBOFB3wo7P4/6bPX0ljGbl7IMEK7lnQOyCzzBR4cgJla0qHrKPz4viSAs= Received: from MN2PR04CA0014.namprd04.prod.outlook.com (2603:10b6:208:d4::27) by DS7PR12MB6119.namprd12.prod.outlook.com (2603:10b6:8:99::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.28; Fri, 22 Sep 2023 09:28:39 +0000 Received: from BL02EPF0001A0FD.namprd03.prod.outlook.com (2603:10b6:208:d4:cafe::a9) by MN2PR04CA0014.outlook.office365.com (2603:10b6:208:d4::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.32 via Frontend Transport; Fri, 22 Sep 2023 09:28:38 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF0001A0FD.mail.protection.outlook.com (10.167.242.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6792.20 via Frontend Transport; Fri, 22 Sep 2023 09:28:38 +0000 Received: from beas.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 22 Sep 2023 04:28:36 -0500 From: Wyes Karny <wyes.karny@amd.com> To: <lenb@kernel.org> CC: <linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Wyes Karny <wyes.karny@amd.com> Subject: [PATCH] tools/power turbostat: Increase the limit for fd opened Date: Fri, 22 Sep 2023 09:28:23 +0000 Message-ID: <20230922092823.478042-1-wyes.karny@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A0FD:EE_|DS7PR12MB6119:EE_ X-MS-Office365-Filtering-Correlation-Id: 4fc895ab-dde7-454e-ad0e-08dbbb4e4da6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rdvDzuSF0D/q8i0ZFUfjMbx+S2WPmyCv2RrdLuhCmi3AcQP0e/CrTtn6IYkmURm/s6K4GeYGf6Ho3QpF4EX3eUI4aGBouutd5Rmff56xbsAe4S6/II7nMBVwLoGQuzdQHm97FMpd5aw/1JJdIKDRtJTpQCxnaAoAniX/U41h0HTbR22cP0gWdvP8CAvAKeVRiPsnqGmkvZJDLMoVD4N1Fwsue3TCXvH8dZJR+aO+WVSrswvgQhrZGvNWBDjh3mm+WD6RBUFS90mLweY+tdYNxNZZ476FdZUuzyPaq6xT0ykAcY0AwNmlcqMRqseMedRHX0baKdbOL7u1OlKR91Q+crihguygvIHBTVL/14CaUTO+DIMM0CnUGvGBLEVY8zT2nqo6doAPvqCsf91yq9NbhGHBwXuN452ubF27lGYs/PUm3eEIFLHFmTFaI3m4BrByBUvrEw0sa6DCKwB5SFlm+0/rPvZQrlnl51EYMgZw2DSLrBc57VbYyNIieUSC2eveqnFDBYy9dQtEj5S4szKKlL0S54LLRHdsEHKRgaZcQnWr0Jwq0JFZMSXPyRPsVm6W5ZC8kVO+7NuH4sKlbyXA8wi0lRJh8jgHPk1aUsNWQN0PfjJSiJjkF+5uJwS3L5OgWqMBk444inOSHN80WwU0erpLiHkoLdg+lr4Ks6XIOLLi+eF5hDG/PJAONbFCNCtmo6ZzXNZBu5lfaMQ52jCJH6vAx5Z330jI4mdYlCwPB8/9QFqTsUgFQbDtaGrHy36yvukEdRPFI/1ZWFolVBb6DbZWkYzeQL1Lr5qLIgrr/LHdsyet95eINYb2iLGJd5EW X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(396003)(346002)(136003)(376002)(39860400002)(451199024)(1800799009)(186009)(230921699003)(82310400011)(36840700001)(40470700004)(46966006)(6666004)(7696005)(426003)(40480700001)(40460700003)(36756003)(356005)(82740400003)(26005)(36860700001)(86362001)(40140700001)(2906002)(478600001)(83380400001)(47076005)(41300700001)(70206006)(6916009)(70586007)(16526019)(4326008)(8936002)(5660300002)(2616005)(1076003)(316002)(8676002)(54906003)(81166007)(44832011)(336012)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2023 09:28:38.7200 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4fc895ab-dde7-454e-ad0e-08dbbb4e4da6 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A0FD.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6119 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Fri, 22 Sep 2023 02:28:46 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777775642912497489 X-GMAIL-MSGID: 1777775642912497489 |
Series |
tools/power turbostat: Increase the limit for fd opened
|
|
Commit Message
Wyes Karny
Sept. 22, 2023, 9:28 a.m. UTC
When running turbostat, a system with 512 cpus reaches the limit for
maximum number of file descriptors that can be opened. To solve this
problem, the limit is raised to 2^15, which is a large enough number.
Below data is collected from AMD server systems while running turbostat:
|-----------+-------------------------------|
| # of cpus | # of opened fds for turbostat |
|-----------+-------------------------------|
| 128 | 260 |
|-----------+-------------------------------|
| 192 | 388 |
|-----------+-------------------------------|
| 512 | 1028 |
|-----------+-------------------------------|
So, the new max limit would be sufficient up to 2^14 cpus.
Signed-off-by: Wyes Karny <wyes.karny@amd.com>
---
tools/power/x86/turbostat/turbostat.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
Comments
On 2023.09.22 02:28 Wyes Karny wrote: > When running turbostat, a system with 512 cpus reaches the limit for Suggest" ... reaches the default limit for..." > maximum number of file descriptors that can be opened. To solve this > problem, the limit is raised to 2^15, which is a large enough number. > > Below data is collected from AMD server systems while running turbostat: > > |-----------+-------------------------------| > | # of cpus | # of opened fds for turbostat | > |-----------+-------------------------------| > | 128 | 260 | > |-----------+-------------------------------| > | 192 | 388 | > |-----------+-------------------------------| > | 512 | 1028 | > |-----------+-------------------------------| The number of open files is a function of what is being "show"ed or "hide"en. They can also increase beyond the above 2 X (# of CPUs) + 4 number via the --add directive. > > So, the new max limit would be sufficient up to 2^14 cpus. Well, not quiet, but the point is valid. Normally, I would assume that a server with a large number of CPUs would have set a much higher limit of the number of open files than the default. I use 131,072 and so this patch reduces the maximum. Unpatched: root@s19:~# cat /proc/47043/limits | grep "Max open files" Max open files 131072 131072 files Patched: root@s19:~# cat /proc/47032/limits | grep "Max open files" Max open files 32768 32768 files Anyway: Reviewed-by: Doug Smythies <dsmythies@telus.net> Tested-by: Doug Smythies <dsmythies@telus.net> > > Signed-off-by: Wyes Karny <wyes.karny@amd.com> > --- > tools/power/x86/turbostat/turbostat.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c > index 9a10512e3407..23f1fe58289a 100644 > --- a/tools/power/x86/turbostat/turbostat.c > +++ b/tools/power/x86/turbostat/turbostat.c > @@ -6717,6 +6717,18 @@ void cmdline(int argc, char **argv) > } > } > > +void set_rlimit(void) > +{ > + struct rlimit limit; > + > + limit.rlim_cur = 0x8000; > + limit.rlim_max = 0x8000; > + > + if (setrlimit(RLIMIT_NOFILE, &limit) < 0) { > + err(1, "Failed to set rlimit"); > + } > +} > + > int main(int argc, char **argv) > { > outf = stderr; > @@ -6729,6 +6741,9 @@ int main(int argc, char **argv) > > probe_sysfs(); > > + if (!getuid()) > + set_rlimit(); > + > turbostat_init(); > > msr_sum_record(); > -- > 2.34.1 >
Hi Doug, Thanks for taking a look at the patch. On 22 Sep 13:48, Doug Smythies wrote: > On 2023.09.22 02:28 Wyes Karny wrote: > > > When running turbostat, a system with 512 cpus reaches the limit for > > Suggest" ... reaches the default limit for..." > > > maximum number of file descriptors that can be opened. To solve this > > problem, the limit is raised to 2^15, which is a large enough number. > > > > Below data is collected from AMD server systems while running turbostat: > > > > |-----------+-------------------------------| > > | # of cpus | # of opened fds for turbostat | > > |-----------+-------------------------------| > > | 128 | 260 | > > |-----------+-------------------------------| > > | 192 | 388 | > > |-----------+-------------------------------| > > | 512 | 1028 | > > |-----------+-------------------------------| > > The number of open files is a function of what is being "show"ed or "hide"en. > They can also increase beyond the above 2 X (# of CPUs) + 4 number > via the --add directive. > > > > So, the new max limit would be sufficient up to 2^14 cpus. > > Well, not quiet, but the point is valid. > > Normally, I would assume that a server with a large number of > CPUs would have set a much higher limit of the number of open > files than the default. I use 131,072 and so this patch reduces the > maximum. I think below will fix the problem. +#define MAX_NOFILE 0x8000 + +void set_rlimit(void) +{ + struct rlimit limit; + + if(getrlimit(RLIMIT_NOFILE, &limit) < 0) { + err(1, "Failed to get rlimit"); + } + + if (limit.rlim_max < MAX_NOFILE) + limit.rlim_max = MAX_NOFILE; + if (limit.rlim_cur < MAX_NOFILE) + limit.rlim_cur = MAX_NOFILE; + + if (setrlimit(RLIMIT_NOFILE, &limit) < 0) { + err(1, "Failed to set rlimit"); + } + return; +} Is this looks okay to you? Thanks, Wyes > > Unpatched: > root@s19:~# cat /proc/47043/limits | grep "Max open files" > Max open files 131072 131072 files > > Patched: > root@s19:~# cat /proc/47032/limits | grep "Max open files" > Max open files 32768 32768 files > > Anyway: > > Reviewed-by: Doug Smythies <dsmythies@telus.net> > Tested-by: Doug Smythies <dsmythies@telus.net> > > > > > Signed-off-by: Wyes Karny <wyes.karny@amd.com> > > --- > > tools/power/x86/turbostat/turbostat.c | 15 +++++++++++++++ > > 1 file changed, 15 insertions(+) > > > > diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c > > index 9a10512e3407..23f1fe58289a 100644 > > --- a/tools/power/x86/turbostat/turbostat.c > > +++ b/tools/power/x86/turbostat/turbostat.c > > @@ -6717,6 +6717,18 @@ void cmdline(int argc, char **argv) > > } > > } > > > > +void set_rlimit(void) > > +{ > > + struct rlimit limit; > > + > > + limit.rlim_cur = 0x8000; > > + limit.rlim_max = 0x8000; > > + > > + if (setrlimit(RLIMIT_NOFILE, &limit) < 0) { > > + err(1, "Failed to set rlimit"); > > + } > > +} > > + > > int main(int argc, char **argv) > > { > > outf = stderr; > > @@ -6729,6 +6741,9 @@ int main(int argc, char **argv) > > > > probe_sysfs(); > > > > + if (!getuid()) > > + set_rlimit(); > > + > > turbostat_init(); > > > > msr_sum_record(); > > -- > > 2.34.1 > > >
Hi Wyes, On 2023.09.26 10:16 Wyes Karny wrote: > On 22 Sep 13:48, Doug Smythies wrote: > > On 2023.09.22 02:28 Wyes Karny wrote: > > > > > When running turbostat, a system with 512 cpus reaches the limit for > > > > Suggest" ... reaches the default limit for..." > > > > > maximum number of file descriptors that can be opened. To solve this > > > problem, the limit is raised to 2^15, which is a large enough number. > > > > > > Below data is collected from AMD server systems while running turbostat: > > > > > > |-----------+-------------------------------| > > > | # of cpus | # of opened fds for turbostat | > > > |-----------+-------------------------------| > > > | 128 | 260 | > > > |-----------+-------------------------------| > > > | 192 | 388 | > > > |-----------+-------------------------------| > > > | 512 | 1028 | > > > |-----------+-------------------------------| > > > > The number of open files is a function of what is being "show"ed or "hide"en. > > They can also increase beyond the above 2 X (# of CPUs) + 4 number > > via the --add directive. > > > > > > So, the new max limit would be sufficient up to 2^14 cpus. > > > > Well, not quiet, but the point is valid. > > > > Normally, I would assume that a server with a large number of > > CPUs would have set a much higher limit of the number of open > > files than the default. I use 131,072 and so this patch reduces the > > maximum. > > I think below will fix the problem. > > +#define MAX_NOFILE 0x8000 > + > +void set_rlimit(void) > +{ > + struct rlimit limit; > + > + if(getrlimit(RLIMIT_NOFILE, &limit) < 0) { > + err(1, "Failed to get rlimit"); > + } > + > + if (limit.rlim_max < MAX_NOFILE) > + limit.rlim_max = MAX_NOFILE; > + if (limit.rlim_cur < MAX_NOFILE) > + limit.rlim_cur = MAX_NOFILE; > + > + if (setrlimit(RLIMIT_NOFILE, &limit) < 0) { > + err(1, "Failed to set rlimit"); > + } > + return; > +} > > Is this looks okay to you? Either the original or the above is fine. I was just being nit-picky and annoying is all. I still added a "Reviewed-by" below. ... Doug > Thanks, > Wyes > > > > Unpatched: > > root@s19:~# cat /proc/47043/limits | grep "Max open files" > > Max open files 131072 131072 files > > > > Patched: > > root@s19:~# cat /proc/47032/limits | grep "Max open files" > > Max open files 32768 32768 files > > > > Anyway: > > > > Reviewed-by: Doug Smythies <dsmythies@telus.net> > > Tested-by: Doug Smythies <dsmythies@telus.net> > > > > > > > > Signed-off-by: Wyes Karny <wyes.karny@amd.com> > > > --- > > > tools/power/x86/turbostat/turbostat.c | 15 +++++++++++++++ > > > 1 file changed, 15 insertions(+) > > > > > > diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c > > > index 9a10512e3407..23f1fe58289a 100644 > > > --- a/tools/power/x86/turbostat/turbostat.c > > > +++ b/tools/power/x86/turbostat/turbostat.c > > > @@ -6717,6 +6717,18 @@ void cmdline(int argc, char **argv) > > > } > > > } > > > > > > +void set_rlimit(void) > > > +{ > > > + struct rlimit limit; > > > + > > > + limit.rlim_cur = 0x8000; > > > + limit.rlim_max = 0x8000; > > > + > > > + if (setrlimit(RLIMIT_NOFILE, &limit) < 0) { > > > + err(1, "Failed to set rlimit"); > > > + } > > > +} > > > + > > > int main(int argc, char **argv) > > > { > > > outf = stderr; > > > @@ -6729,6 +6741,9 @@ int main(int argc, char **argv) > > > > > > probe_sysfs(); > > > > > > + if (!getuid()) > > > + set_rlimit(); > > > + > > > turbostat_init(); > > > > > > msr_sum_record(); > > > -- > > > 2.34.1
diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index 9a10512e3407..23f1fe58289a 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -6717,6 +6717,18 @@ void cmdline(int argc, char **argv) } } +void set_rlimit(void) +{ + struct rlimit limit; + + limit.rlim_cur = 0x8000; + limit.rlim_max = 0x8000; + + if (setrlimit(RLIMIT_NOFILE, &limit) < 0) { + err(1, "Failed to set rlimit"); + } +} + int main(int argc, char **argv) { outf = stderr; @@ -6729,6 +6741,9 @@ int main(int argc, char **argv) probe_sysfs(); + if (!getuid()) + set_rlimit(); + turbostat_init(); msr_sum_record();