Message ID | 167278360189.34228.2442698916556329960.stgit@bmoger-ubuntu |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp4837837wrt; Tue, 3 Jan 2023 14:08:42 -0800 (PST) X-Google-Smtp-Source: AMrXdXtudYbK+SdEa4ohO+fqSNluwdtLMWr+IVL6Yk7cpL0N12/UhWq8h5abBjGaJITiaaMMsZ+s X-Received: by 2002:aa7:8f8e:0:b0:581:c0ee:3a5e with SMTP id t14-20020aa78f8e000000b00581c0ee3a5emr20338200pfs.20.1672783721974; Tue, 03 Jan 2023 14:08:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1672783721; cv=pass; d=google.com; s=arc-20160816; b=BY/KIUGvbiF30TmwjaX8DgCIwO480T7lbZyZU+lI5QihA/ECjXKkDevXU0sMwi06t5 +jxggCost4MKEfX3yX+R5raDDcra7Hvg3zjL7O3lgmRSXwuzc/cXtVtJ24ILoIWDejpL SHNf5W/P6fLzhxbfMzi512xNVUVb0Voe6bpj6hGcrasZpSSiZXTeR8L01FVYBCfgbavu 1bCzD56RtDu9vp9gN/WgutqyrbJwCsDyUFhOoO8eSw4CJPRhjYNKxkhtknDv8aZGn7L3 LJEQqn3tAkNHNYfUSmoCQOK+903uOj+V+/D71zT8S/H6ksDWZ+SboATPKw2BmcL84mKl NyOg== 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 :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:dkim-signature; bh=pf+NVcrXEfYCXvA+xTtaovDfj4mw15ywKxmSHmquV6I=; b=AwuCvZI07YKbKyKJ8we4C9v+u3KMKJG6HhpagDLrzX2W2gxnuY7eeCG0Y796+iJvmt 8sKrJCzzdkrQHT11+Gd058/h5PCTbGpsTPTCP+K57lDVWe7sSQbXADVKuPJTekcicun0 rzLufiV3mZVHe79vYQGC8/g/m6o4I4+fNU/zgCekXX+6GbIu/226dr3W7H6Kn67kQw5K Jv8AsisIjQbWsa3gwz0kybOQ6tbBpoOJxUORnvz4pp59x0pNfio2jGK6fnDAJzxvIOtv mx/DmAK3BAygyzLb/bf3qVJrGtZSXrWfHqohB5sKY+C8oHrBS9vA+pVMlaKW0JhzBZVw Of4Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=2xjTjSoe; 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 2620:137:e000::1:20 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 (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z3-20020aa78883000000b00582c72e5c4csi2430834pfe.181.2023.01.03.14.08.30; Tue, 03 Jan 2023 14:08:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=2xjTjSoe; 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 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238547AbjACWHp (ORCPT <rfc822;tmhikaru@gmail.com> + 99 others); Tue, 3 Jan 2023 17:07:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238426AbjACWHG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 3 Jan 2023 17:07:06 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2073.outbound.protection.outlook.com [40.107.93.73]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A1B2E026; Tue, 3 Jan 2023 14:06:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jXDhfEPUP+BTDEHaj997Dv7PHhX2Jk1EwY+uwHVESX0f63Wb2rcDewiLRhYQCk1B+JqBr9dyfCB7l5PLhe6CKWaeYTn1cQNMPdZzTpe2ZnV1UCEfbm/egmDiZDp/oOXx2madVL24RDRm0qEdS3IcyV8hbI1QK5ITrydwGPFOK6JxSfT4mXYIkrAlMUJe9Y1M20Z1u1gU/PhLajWhkgKj5BinO2AA6YJaci8Y3rpw7upZudEe4xuz/kV+ANw4hcrYZtKcb/VTxg8UducCNmPwHNaxWrLAPv0U7GcW06jqtzdCrebikX0ji3DxXdftGi7mIunSVVKgxfdYnWdYgcb9lA== 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=pf+NVcrXEfYCXvA+xTtaovDfj4mw15ywKxmSHmquV6I=; b=eeiaDtouvPxoTRXC8wpgzh8mxz3EEvggA7qPJpennZzScwcP5NJ4bMtRvHLhyDvCQuGFF5pRMPI4+rumSF1/UWl4tebp1mr4GwGQBlzs1o45PPyuNPqnovNQJeaysGzNNgoE1cL0LlMAvijp+M5FgnfYgF7a5ArbePywmsdXWpt6CSr2zyI+sgq2XfJ9AIrlly9mMchBgrRrIsi4oMDprVDsaqGwH38Ntbe6VkCU/StULetWELfReGkQU97LFnLlCsyG6UaR81kFXJxscPdLeOl8mMBUOHWpt5Pgc2d41ZfYDnToY9pw2+bUQ6/pdIl75uMcSGgt7jiS+QQmDAORwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=linutronix.de 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=pf+NVcrXEfYCXvA+xTtaovDfj4mw15ywKxmSHmquV6I=; b=2xjTjSoe7K2BKPoo4dbGfJkotpD8mtS0ePy6xlqxXYDrR+zC6zlRSSHt1Oa4ayqeSwdKjen1+iDDuoBLDKKsP91UmqtMcFQLGlbV47DIitGXDoT9xKgOz0GU9BY3UIeqGjSAKwbpIWEuyffA76lgNr2Omu5BHRnNGcX633yxVws= Received: from DM6PR12CA0036.namprd12.prod.outlook.com (2603:10b6:5:1c0::49) by DS0PR12MB7948.namprd12.prod.outlook.com (2603:10b6:8:152::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5944.19; Tue, 3 Jan 2023 22:06:48 +0000 Received: from DS1PEPF0000E63E.namprd02.prod.outlook.com (2603:10b6:5:1c0:cafe::a1) by DM6PR12CA0036.outlook.office365.com (2603:10b6:5:1c0::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5966.19 via Frontend Transport; Tue, 3 Jan 2023 22:06:48 +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 DS1PEPF0000E63E.mail.protection.outlook.com (10.167.17.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5944.8 via Frontend Transport; Tue, 3 Jan 2023 22:06:48 +0000 Received: from [127.0.1.1] (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.2375.34; Tue, 3 Jan 2023 16:06:47 -0600 Subject: [RFC PATCH 2/3] x86/resctrl: Move the task's threads to the group automatically From: Babu Moger <babu.moger@amd.com> To: <fenghua.yu@intel.com>, <reinette.chatre@intel.com> CC: <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>, <dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>, <corbet@lwn.net>, <linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>, <eranian@google.com>, <peternewman@google.com> Date: Tue, 3 Jan 2023 16:06:41 -0600 Message-ID: <167278360189.34228.2442698916556329960.stgit@bmoger-ubuntu> In-Reply-To: <167278351577.34228.12803395505584557101.stgit@bmoger-ubuntu> References: <167278351577.34228.12803395505584557101.stgit@bmoger-ubuntu> User-Agent: StGit/1.1.dev103+g5369f4c MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: DS1PEPF0000E63E:EE_|DS0PR12MB7948:EE_ X-MS-Office365-Filtering-Correlation-Id: 1389525f-b800-487b-26ad-08daedd6cf90 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: aRx0cpDZTUwfL9QtUuVAoDVfah3WwFZTL22E4WX/leA+h17Dt+fPlRXzIxpmZD+qojfl2XlfUnqaYqNQVRsY8WwOfhlmRkXNOa/D+R4SzFzvDHNbm1lSJ2AK9OUxqCWz6CqCiZz0XvOKHYbmXJumSACiTNl/b6rObTTlgJkTnRTjjiKn4ewmvA2kqcAZk9FbN6egJnuLdYEi6HFOaccgI8E53ybKIl/3xBH6IL/SgW8+ukkADjhf7tKeehAKy+KCl4DPeANY3kEbD+YJlolMe1KxLFGS0KqD3L4suPhU3as91kTVUJkOvLOgibJNSn//Y0W5LLLYdI5qbK2ErMiecXHbAQDEgt60iG/rjHYkMaxTCQl/wdeJfmsC8ygKkfhTvdpeXnpEcP46v13/RkE8EPl0oqAnjK5YetNl9EUlfetJ11bdOnnoITDZJbdXLv3TI8SzXT2jfru3ikUR8FLYFn/arCXBE39/Y1anFKRJAbOUqm/WrXiKhwAKFawPy7XMp6CG0LMOBkv3cFlIgbw5oP0wiAhS/SNtW7A8cEMzdTMVBjkfg3Ztt/K/mDtyqI78tXp9VFz+6uGX5HocI6y3v8biAWnUuSGAWEw707gA/SQmpeMsQvQFn7mrPlX6FuEmp2A14jZQuYUm4yP8sJwB6V+SbwzhVoF7TVLq9PD41RCNZdsQY5ckMV217Q4XSEuYSYx9wCJrLZqZ+avURUjcwzVayj/c5J8UND97U7THhTGES0F5VGgA+Teh5y+HDDsgR5UGcPArclbO+x5hMX4wmENE/MTs6AI1CFQSTFRz7zU= 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:(13230022)(7916004)(4636009)(346002)(396003)(136003)(39860400002)(376002)(451199015)(36840700001)(46966006)(40470700004)(81166007)(82740400003)(356005)(103116003)(86362001)(70206006)(70586007)(8676002)(54906003)(4326008)(110136005)(41300700001)(82310400005)(426003)(40460700003)(7416002)(16526019)(40480700001)(2906002)(5660300002)(316002)(8936002)(16576012)(9686003)(336012)(47076005)(44832011)(83380400001)(33716001)(478600001)(26005)(186003)(36860700001)(6666004)(66899015)(22166009)(71626007)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jan 2023 22:06:48.6680 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1389525f-b800-487b-26ad-08daedd6cf90 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: DS1PEPF0000E63E.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7948 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham 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-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754040863871876876?= X-GMAIL-MSGID: =?utf-8?q?1754040863871876876?= |
Series |
x86/resctrl: Miscellaneous resctrl features
|
|
Commit Message
Moger, Babu
Jan. 3, 2023, 10:06 p.m. UTC
Some micro benchmarks run multiple threads when started. Monitoring
(or controlling) the benchmark using the task id is bit tricky. Users
need to track all the threads and assign them individually to monitor
or control. For example:
$stream_lowOverhead -codeAlg 13 -nRep 100000 -cores 0 1 2 3 -memMB 32
-alignKB 8192 -aPadB 0 -bPadB 0 -cPadB 0 -testMask 1
$pidof stream_lowOverhead
6793
This benchmark actually runs multiple threads underneath on the cores
listed above. It can be seen with the command:
$ps -T -p 6793
PID SPID TTY TIME CMD
6793 6793 pts/2 00:00:00 stream_lowOverh
6793 6802 pts/2 00:01:25 stream_lowOverh
6793 6803 pts/2 00:01:25 stream_lowOverh
6793 6804 pts/2 00:01:25 stream_lowOverh
6793 6805 pts/2 00:01:25 stream_lowOverh
Users need to assign these threads individually to the resctrl group for
monitoring or controlling.
$echo 6793 > /sys/fs/restrl/clos1/tasks
$echo 6802 > /sys/fs/restrl/clos1/tasks
$echo 6803 > /sys/fs/restrl/clos1/tasks
$echo 6804 > /sys/fs/restrl/clos1/tasks
$echo 6805 > /sys/fs/restrl/clos1/tasks
That is not easy when dealing with numerous threads.
Detect the task's threads automatically and assign them to the resctrl
group when parent task is assigned. For example:
$echo 6793 > /sys/fs/restrl/clos1/tasks
All the threads will be assigned to the group automatically.
$cat /sys/fs/restrl/clos1/tasks
6793
6793
6802
6803
6804
6805
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Comments
Hi, Babu, > Some micro benchmarks run multiple threads when started. Monitoring (or > controlling) the benchmark using the task id is bit tricky. Users need to track all > the threads and assign them individually to monitor or control. For example: > $stream_lowOverhead -codeAlg 13 -nRep 100000 -cores 0 1 2 3 -memMB 32 > -alignKB 8192 -aPadB 0 -bPadB 0 -cPadB 0 -testMask 1 > > $pidof stream_lowOverhead > 6793 > > This benchmark actually runs multiple threads underneath on the cores listed > above. It can be seen with the command: > $ps -T -p 6793 > PID SPID TTY TIME CMD > 6793 6793 pts/2 00:00:00 stream_lowOverh > 6793 6802 pts/2 00:01:25 stream_lowOverh > 6793 6803 pts/2 00:01:25 stream_lowOverh > 6793 6804 pts/2 00:01:25 stream_lowOverh > 6793 6805 pts/2 00:01:25 stream_lowOverh > > Users need to assign these threads individually to the resctrl group for > monitoring or controlling. > > $echo 6793 > /sys/fs/restrl/clos1/tasks > $echo 6802 > /sys/fs/restrl/clos1/tasks > $echo 6803 > /sys/fs/restrl/clos1/tasks > $echo 6804 > /sys/fs/restrl/clos1/tasks > $echo 6805 > /sys/fs/restrl/clos1/tasks > > That is not easy when dealing with numerous threads. > > Detect the task's threads automatically and assign them to the resctrl group > when parent task is assigned. For example: But user may choose not to move threads along with the parent. You will need to have an option to opt in. > $echo 6793 > /sys/fs/restrl/clos1/tasks > > All the threads will be assigned to the group automatically. > $cat /sys/fs/restrl/clos1/tasks > 6793 > 6793 > 6802 > 6803 > 6804 > 6805 > > Signed-off-by: Babu Moger <babu.moger@amd.com> > --- > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > index 344607853f4c..0d71ed22cfa9 100644 > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > @@ -685,6 +685,7 @@ static int rdtgroup_move_task(pid_t pid, struct rdtgroup > *rdtgrp, static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of, > char *buf, size_t nbytes, loff_t off) { > + struct task_struct *task, *thread; > struct rdtgroup *rdtgrp; > char *pid_str; > int ret = 0; > @@ -723,7 +724,13 @@ static ssize_t rdtgroup_tasks_write(struct > kernfs_open_file *of, > goto exit; > } > > - ret = rdtgroup_move_task(pid, rdtgrp, of); > + task = find_task_by_vpid(pid); > + thread = task; > + do { > + ret = rdtgroup_move_task(thread->pid, rdtgrp, of); > + if (ret) > + goto exit; If failure happens in the middle of threads, will you reverse the previous moved threads (or even the task) or will you report this failure and move to the next thread? Seems to me you need to either move all threads or no thread moved at all. > + } while_each_thread(task, thread); > > goto next; > > Thanks. -Fenghua
Hi Babu, On 1/3/2023 2:06 PM, Babu Moger wrote: > Some micro benchmarks run multiple threads when started. Monitoring > (or controlling) the benchmark using the task id is bit tricky. Users > need to track all the threads and assign them individually to monitor > or control. For example: > $stream_lowOverhead -codeAlg 13 -nRep 100000 -cores 0 1 2 3 -memMB 32 > -alignKB 8192 -aPadB 0 -bPadB 0 -cPadB 0 -testMask 1 > > $pidof stream_lowOverhead > 6793 > > This benchmark actually runs multiple threads underneath on the cores > listed above. It can be seen with the command: > $ps -T -p 6793 > PID SPID TTY TIME CMD > 6793 6793 pts/2 00:00:00 stream_lowOverh > 6793 6802 pts/2 00:01:25 stream_lowOverh > 6793 6803 pts/2 00:01:25 stream_lowOverh > 6793 6804 pts/2 00:01:25 stream_lowOverh > 6793 6805 pts/2 00:01:25 stream_lowOverh > > Users need to assign these threads individually to the resctrl group for > monitoring or controlling. > > $echo 6793 > /sys/fs/restrl/clos1/tasks > $echo 6802 > /sys/fs/restrl/clos1/tasks > $echo 6803 > /sys/fs/restrl/clos1/tasks > $echo 6804 > /sys/fs/restrl/clos1/tasks > $echo 6805 > /sys/fs/restrl/clos1/tasks > > That is not easy when dealing with numerous threads. How about: # echo $$ > /sys/fs/resctrl/clos1/tasks # stream_lowOverhead -codeAlg 13 -nRep 100000 -cores 0 1 2 3 -memMB 32\ -alignKB 8192 -aPadB 0 -bPadB 0 -cPadB 0 -testMask 1 Reinette
Hi Fenghua, On 1/3/23 23:55, Yu, Fenghua wrote: > Hi, Babu, > >> Some micro benchmarks run multiple threads when started. Monitoring (or >> controlling) the benchmark using the task id is bit tricky. Users need to track all >> the threads and assign them individually to monitor or control. For example: >> $stream_lowOverhead -codeAlg 13 -nRep 100000 -cores 0 1 2 3 -memMB 32 >> -alignKB 8192 -aPadB 0 -bPadB 0 -cPadB 0 -testMask 1 >> >> $pidof stream_lowOverhead >> 6793 >> >> This benchmark actually runs multiple threads underneath on the cores listed >> above. It can be seen with the command: >> $ps -T -p 6793 >> PID SPID TTY TIME CMD >> 6793 6793 pts/2 00:00:00 stream_lowOverh >> 6793 6802 pts/2 00:01:25 stream_lowOverh >> 6793 6803 pts/2 00:01:25 stream_lowOverh >> 6793 6804 pts/2 00:01:25 stream_lowOverh >> 6793 6805 pts/2 00:01:25 stream_lowOverh >> >> Users need to assign these threads individually to the resctrl group for >> monitoring or controlling. >> >> $echo 6793 > /sys/fs/restrl/clos1/tasks >> $echo 6802 > /sys/fs/restrl/clos1/tasks >> $echo 6803 > /sys/fs/restrl/clos1/tasks >> $echo 6804 > /sys/fs/restrl/clos1/tasks >> $echo 6805 > /sys/fs/restrl/clos1/tasks >> >> That is not easy when dealing with numerous threads. >> >> Detect the task's threads automatically and assign them to the resctrl group >> when parent task is assigned. For example: > But user may choose not to move threads along with the parent. > You will need to have an option to opt in. Yes. I agree. > >> $echo 6793 > /sys/fs/restrl/clos1/tasks >> >> All the threads will be assigned to the group automatically. >> $cat /sys/fs/restrl/clos1/tasks >> 6793 >> 6793 >> 6802 >> 6803 >> 6804 >> 6805 >> >> Signed-off-by: Babu Moger <babu.moger@amd.com> >> --- >> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> index 344607853f4c..0d71ed22cfa9 100644 >> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> @@ -685,6 +685,7 @@ static int rdtgroup_move_task(pid_t pid, struct rdtgroup >> *rdtgrp, static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of, >> char *buf, size_t nbytes, loff_t off) { >> + struct task_struct *task, *thread; >> struct rdtgroup *rdtgrp; >> char *pid_str; >> int ret = 0; >> @@ -723,7 +724,13 @@ static ssize_t rdtgroup_tasks_write(struct >> kernfs_open_file *of, >> goto exit; >> } >> >> - ret = rdtgroup_move_task(pid, rdtgrp, of); >> + task = find_task_by_vpid(pid); >> + thread = task; >> + do { >> + ret = rdtgroup_move_task(thread->pid, rdtgrp, of); >> + if (ret) >> + goto exit; > If failure happens in the middle of threads, will you reverse the previous > moved threads (or even the task) or will you report this failure and move > to the next thread? Seems to me you need to either move all threads or > no thread moved at all. Yes. We should handle the failures properly. Reversing all previous movements requires quite a bit of book keeping. As a work-around Reinette's comment "echo $$ > /sys/fs/resctrl/clos1/tasks" seems to move all the threads. I will have to think about this more closely. Thanks Babu > >> + } while_each_thread(task, thread); >> >> goto next; >> >> > Thanks. > > -Fenghua
Hi Reinette, On 1/4/23 10:43, Reinette Chatre wrote: > Hi Babu, > > On 1/3/2023 2:06 PM, Babu Moger wrote: >> Some micro benchmarks run multiple threads when started. Monitoring >> (or controlling) the benchmark using the task id is bit tricky. Users >> need to track all the threads and assign them individually to monitor >> or control. For example: >> $stream_lowOverhead -codeAlg 13 -nRep 100000 -cores 0 1 2 3 -memMB 32 >> -alignKB 8192 -aPadB 0 -bPadB 0 -cPadB 0 -testMask 1 >> >> $pidof stream_lowOverhead >> 6793 >> >> This benchmark actually runs multiple threads underneath on the cores >> listed above. It can be seen with the command: >> $ps -T -p 6793 >> PID SPID TTY TIME CMD >> 6793 6793 pts/2 00:00:00 stream_lowOverh >> 6793 6802 pts/2 00:01:25 stream_lowOverh >> 6793 6803 pts/2 00:01:25 stream_lowOverh >> 6793 6804 pts/2 00:01:25 stream_lowOverh >> 6793 6805 pts/2 00:01:25 stream_lowOverh >> >> Users need to assign these threads individually to the resctrl group for >> monitoring or controlling. >> >> $echo 6793 > /sys/fs/restrl/clos1/tasks >> $echo 6802 > /sys/fs/restrl/clos1/tasks >> $echo 6803 > /sys/fs/restrl/clos1/tasks >> $echo 6804 > /sys/fs/restrl/clos1/tasks >> $echo 6805 > /sys/fs/restrl/clos1/tasks >> >> That is not easy when dealing with numerous threads. > How about: > > # echo $$ > /sys/fs/resctrl/clos1/tasks > # stream_lowOverhead -codeAlg 13 -nRep 100000 -cores 0 1 2 3 -memMB 32\ > -alignKB 8192 -aPadB 0 -bPadB 0 -cPadB 0 -testMask 1 Yes, That works. We can use that as a work-around for now. I will drop this patch for now. I will have to figure out how to handle failures in the middle of task/thread movement. Will have to revisit this in the future. Will re-submit patch 1 and 3. Thanks Babu > > Reinette
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index 344607853f4c..0d71ed22cfa9 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -685,6 +685,7 @@ static int rdtgroup_move_task(pid_t pid, struct rdtgroup *rdtgrp, static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of, char *buf, size_t nbytes, loff_t off) { + struct task_struct *task, *thread; struct rdtgroup *rdtgrp; char *pid_str; int ret = 0; @@ -723,7 +724,13 @@ static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of, goto exit; } - ret = rdtgroup_move_task(pid, rdtgrp, of); + task = find_task_by_vpid(pid); + thread = task; + do { + ret = rdtgroup_move_task(thread->pid, rdtgrp, of); + if (ret) + goto exit; + } while_each_thread(task, thread); goto next;