Message ID | 20240126130213.159339-1-haifeng.xu@shopee.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-40116-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:e09d:b0:103:945f:af90 with SMTP id gm29csp642109dyb; Fri, 26 Jan 2024 05:03:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IE9jVz91Qv9QX5/+fAIQ3mOJevTvYJoswinbUub9TPyGvQhaisGavMhVGYHbqfCE69FlZAr X-Received: by 2002:a05:6a21:1a7:b0:19c:6cae:5386 with SMTP id le39-20020a056a2101a700b0019c6cae5386mr1191529pzb.16.1706274232265; Fri, 26 Jan 2024 05:03:52 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706274232; cv=pass; d=google.com; s=arc-20160816; b=LANit7PQrU9+AwOIFd7uh7BxOA3lPF9CWtWzy24Db2k6wtyQBGBMCOY0VsoTK/qd/Z cT7MEgQXLSuaMePnMdevQvP06I57Qk+iGPlNcMuPaVaxWbm3+3QdVafggkt0w2F0NuPB KM5fsKXRmSoXs+SalQGoqkRzty73/pirgCAiAcNvXXD07GFSyprAH6Uv2pEaF36UBqd0 3FVgz5vYRQz2EEHCdFy3Z49smAv51SxSeoB3FYMXyNz6ja+dG9EzSiSUi+d4urzahXFW XI2b5fJpwKvVwDnJb1vnjWqoEB6v5Aioh2ARs3cbuZ9erGfgtMcyG2fi8qDY6E/V+/gQ 29MQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=t9J/yZkugauITzzzeewJF5kZsPK6ngxJQMvu/7HtZ40=; fh=mD0RmuXY/RW5SGbCn0hv439g1B5U1hHy6Z7+AEmO8UQ=; b=g2aF/9JQngbHde0dvY/8H3bGXLq/E/gpng32ZK93zAuhVr6t5tReLKMQw6gThOG4ua rSDXAoZE6DeKcETe18axRrvJsaUBzyw9AsUSP8qz13jzdCSZ9nIKpThxNSaAUbdIOvi+ +935GHolWPxsBXbtLzB0hKwBxYXB0nPUbryUF7DbR6djBTkEHvAKo+o4APvw0JnMFq8V 35ixtVlPPGY/7i6iXyZx51GWlI/dZ2sDq1aclvrC2fwrPuJzrf7Bc+q0EIbTvjaaLOLS 3W9fLt78M1E0904/7Z7CTecnLPzCz9+1mPCRfcNM1070xmABgnvhcIDioRafTCvjE4qm XIJQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@shopee.com header.s=shopee.com header.b=IN36Wbo+; arc=pass (i=1 spf=pass spfdomain=shopee.com dkim=pass dkdomain=shopee.com dmarc=pass fromdomain=shopee.com); spf=pass (google.com: domain of linux-kernel+bounces-40116-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-40116-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=shopee.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id e28-20020a63371c000000b005ceb535377bsi1095333pga.521.2024.01.26.05.03.52 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jan 2024 05:03:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-40116-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@shopee.com header.s=shopee.com header.b=IN36Wbo+; arc=pass (i=1 spf=pass spfdomain=shopee.com dkim=pass dkdomain=shopee.com dmarc=pass fromdomain=shopee.com); spf=pass (google.com: domain of linux-kernel+bounces-40116-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-40116-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=shopee.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 5F29C284036 for <ouuuleilei@gmail.com>; Fri, 26 Jan 2024 13:02:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 108A91B819; Fri, 26 Jan 2024 13:02:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=shopee.com header.i=@shopee.com header.b="IN36Wbo+" Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 880271B7EF for <linux-kernel@vger.kernel.org>; Fri, 26 Jan 2024 13:02:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706274155; cv=none; b=PZn5Y93V86U5uY3/WIQ91BKuLYSPgbiG9H1H3GkkUPGN25YYZy3cq1zSbXgv7FmwZS/a1oef/54jQ9BFL/FFvLhtGAG3lzAP68t8rGwarbzrWUxHCr5VD0CWPh2CVuJwb7Zr+vpIQwMociGAKVLv9vU3P3WeB1gA2yw0fJh8JA8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706274155; c=relaxed/simple; bh=EDXuefEciKTCME/A2dMElXxs/lWJf3XhIt3Ju7eSQVk=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Xn/eBE76sT6IN8Bd5zIIVNru2gAuJludflq02amXdNRnUU1o3QUdvkJT5sKwWJHv/hz7edU/ML/HCClmnUZf/LuahfRHjUcgvMdSeiIe8kyMvJoNMLZywGoQfQ1CrSaAV28+LNtKr/ElWaFlR/hi5LY+uCGutRFlfr2oV/+qSkg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=shopee.com; spf=pass smtp.mailfrom=shopee.com; dkim=pass (2048-bit key) header.d=shopee.com header.i=@shopee.com header.b=IN36Wbo+; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=shopee.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shopee.com Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1d71cb97937so1993415ad.3 for <linux-kernel@vger.kernel.org>; Fri, 26 Jan 2024 05:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shopee.com; s=shopee.com; t=1706274153; x=1706878953; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=t9J/yZkugauITzzzeewJF5kZsPK6ngxJQMvu/7HtZ40=; b=IN36Wbo+zE4QyaVLyrQTO4zpB+Mo8mKUqWPAZcgvh4P7M/Lk+BYGt76PRcpEeGDkcX GBn6efG2esUlMf5IbsCe0BTohJa+8kYt3u7EZcagk5oscE8nUucK/ygNjx2jywfUcPgw cgQ8if2RaxrrMgnjTAYqIqWUNPi4isntG+zTG37M1tWh0FT8LAZiUokDLGfjuOcft88k gBzJY6MgpbFhJ8J0NOsxU5ktuV/3DDFC34rLwAaid5E5ZoBog+Z1ga8WCR8dNWJNXC2i DboLFg0PdD56VYKYXT45v9FsdEngjCpEDCzBuks95l8aYlmaFzsI4cjGc/4EkSDWc4xk s4BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706274153; x=1706878953; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=t9J/yZkugauITzzzeewJF5kZsPK6ngxJQMvu/7HtZ40=; b=SQTrIqYGVBwFgJcNSYnFCxygJ211B4/xTZ9bDKXf6QBMpO6nTDBRnlIQne4b/xMzTq HQCwipgronLkmlpDq4EbGhWOCXwFIb4sqgbekXi9ilDMvailwJKau5ngEOyih4NJPEU8 YZeAW9l0vMsi5fxgR0eVPTh7yU+n4LRs11GWQm+xLOIEHpb4nld89bITLN1uNBQlgTYI V6mo3WtgqEeOpXfrDZLqp+tEIN2BoH0bDlmfjttgOkCcgy4jF6iXTLTygwH8PHdRmn3+ 57q1mbFAb2Yg33sGDm/+7skBjFXWsaSaKigxRQhetqE0DwRQwpW2Y3vJV9PsRbKrramN gvaA== X-Gm-Message-State: AOJu0Yzz7tiTIjWmkH9ZnU9bFf8jkNKhbpinLs+BZFbED9bKp2Xowcs9 s+HAvDhHrB/VWR4E3sPbT/Eq6EbvD9Dx2r9tQ7IJ38Z7gJ9WU/2lw6cH4qi7vSY= X-Received: by 2002:a17:902:ee4c:b0:1d7:3adf:b103 with SMTP id 12-20020a170902ee4c00b001d73adfb103mr980734plo.114.1706274152811; Fri, 26 Jan 2024 05:02:32 -0800 (PST) Received: from ubuntu-haifeng.default.svc.cluster.local ([101.127.248.173]) by smtp.gmail.com with ESMTPSA id s22-20020a635256000000b005ca0ae17983sm1020098pgl.8.2024.01.26.05.02.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jan 2024 05:02:32 -0800 (PST) From: Haifeng Xu <haifeng.xu@shopee.com> To: reinette.chatre@intel.com Cc: fenghua.yu@intel.com, babu.moger@amd.com, peternewman@google.com, james.morse@arm.com, x86@kernel.org, linux-kernel@vger.kernel.org, Haifeng Xu <haifeng.xu@shopee.com> Subject: [PATCH] x86/resctrl: Add tracepoint for llc_occupancy tracking Date: Fri, 26 Jan 2024 13:02:13 +0000 Message-Id: <20240126130213.159339-1-haifeng.xu@shopee.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789158209277971671 X-GMAIL-MSGID: 1789158209277971671 |
Series |
x86/resctrl: Add tracepoint for llc_occupancy tracking
|
|
Commit Message
Haifeng Xu
Jan. 26, 2024, 1:02 p.m. UTC
If llc_occupany is enabled, the rmid may not be freed immediately unless
its llc_occupany is less than the resctrl_rmid_realloc_threshold.
In our production environment, those unused rmids get stuck in the limbo
list forever because their llc_occupancy are larger than the threshold.
After turning it up, we can successfully free unused rmids and create
new monitor groups. In order to acquire the llc_occupancy of rmids in
each rdt domain, we use perf tool to track and filter the log manually.
It's not efficient enough. Therefore, we can add a new tracepoint that
shows the llc_occupancy of busy rmids when scanning the limbo list. It
can help us to adjust the resctrl_rmid_realloc_threshold to a reasonable
value.
Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com>
---
arch/x86/kernel/cpu/resctrl/Makefile | 1 +
arch/x86/kernel/cpu/resctrl/monitor.c | 5 ++++
arch/x86/kernel/cpu/resctrl/monitor_event.h | 30 +++++++++++++++++++++
3 files changed, 36 insertions(+)
create mode 100644 arch/x86/kernel/cpu/resctrl/monitor_event.h
Comments
Hi Haifeng, Thank you for proposing this feature. I think it is a useful addition. I tried it out after removing a monitor group and it was insightful to be able to see how the cache occupancy of a removed group shrinks over time. On 1/26/2024 5:02 AM, Haifeng Xu wrote: > If llc_occupany is enabled, the rmid may not be freed immediately unless (llc_occupany -> llc_occupancy ... one more instance below) Please use caps (RMID) for acronym. > its llc_occupany is less than the resctrl_rmid_realloc_threshold. I think it will help to highlight that this is related to monitor group removal. > > In our production environment, those unused rmids get stuck in the limbo > list forever because their llc_occupancy are larger than the threshold. > After turning it up, we can successfully free unused rmids and create > new monitor groups. In order to acquire the llc_occupancy of rmids in > each rdt domain, we use perf tool to track and filter the log manually. Could you please elaborate how you "use perf tool to track and filter the log manually"? > > It's not efficient enough. Therefore, we can add a new tracepoint that "It's not efficient enough." is a vague statement. How was efficiency measured? and what is "enough"? Please do not impersonate code ("we can add a new ...") and stick to the imperative tone. Please see the "Changelog" section in Documentation/process/maintainer-tip.rst for more details. > shows the llc_occupancy of busy rmids when scanning the limbo list. It > can help us to adjust the resctrl_rmid_realloc_threshold to a reasonable > value. > > Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com> > --- > arch/x86/kernel/cpu/resctrl/Makefile | 1 + > arch/x86/kernel/cpu/resctrl/monitor.c | 5 ++++ > arch/x86/kernel/cpu/resctrl/monitor_event.h | 30 +++++++++++++++++++++ > 3 files changed, 36 insertions(+) > create mode 100644 arch/x86/kernel/cpu/resctrl/monitor_event.h > > diff --git a/arch/x86/kernel/cpu/resctrl/Makefile b/arch/x86/kernel/cpu/resctrl/Makefile > index 4a06c37b9cf1..0d3031850d26 100644 > --- a/arch/x86/kernel/cpu/resctrl/Makefile > +++ b/arch/x86/kernel/cpu/resctrl/Makefile > @@ -1,4 +1,5 @@ > # SPDX-License-Identifier: GPL-2.0 > obj-$(CONFIG_X86_CPU_RESCTRL) += core.o rdtgroup.o monitor.o > obj-$(CONFIG_X86_CPU_RESCTRL) += ctrlmondata.o pseudo_lock.o > +CFLAGS_monitor.o = -I$(src) > CFLAGS_pseudo_lock.o = -I$(src) From what I understand only one of the c files should define CREATE_TRACE_POINTS and it is that c file that should have its CFLAGS modified. I do not think it is necessary to preemptively fragment the resctrl tracing by creating a separate header file for the monitor tracepoints. This is something that may be needed as part of current re-design but I think it best to have a simple start that places all tracepoints in the same header file. I would thus like to propose that this work starts by renaming pseudo_lock_event.h to a more generic (trace.h?) that will contain all the tracepoints. pseudo-lock.c is the file that define's CREATE_TRACE_POINTS so it should remain as the only one with its CFLAGS modified. monitor.c should be able to just include "trace.h" (after "trace.h" is updated with the new tracepoint) without needing to define CREATE_TRACE_POINTS. > diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c > index f136ac046851..a6f94fcae174 100644 > --- a/arch/x86/kernel/cpu/resctrl/monitor.c > +++ b/arch/x86/kernel/cpu/resctrl/monitor.c > @@ -24,6 +24,10 @@ > > #include "internal.h" > > +#define CREATE_TRACE_POINTS > +#include "monitor_event.h" > +#undef CREATE_TRACE_POINTS > + > struct rmid_entry { > u32 rmid; > int busy; > @@ -302,6 +306,7 @@ void __check_limbo(struct rdt_domain *d, bool force_free) > } > } > crmid = nrmid + 1; > + trace_rmid_llc_occupancy(nrmid, d->id, val); > } > } > > diff --git a/arch/x86/kernel/cpu/resctrl/monitor_event.h b/arch/x86/kernel/cpu/resctrl/monitor_event.h > new file mode 100644 > index 000000000000..91265a2dd2c9 > --- /dev/null > +++ b/arch/x86/kernel/cpu/resctrl/monitor_event.h > @@ -0,0 +1,30 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#undef TRACE_SYSTEM > +#define TRACE_SYSTEM resctrl > + > +#if !defined(_TRACE_MONITOR_H) || defined(TRACE_HEADER_MULTI_READ) > +#define _TRACE_MONITOR_H > + > +#include <linux/tracepoint.h> > + > +TRACE_EVENT(rmid_llc_occupancy, > + TP_PROTO(u32 rmid, int id, u64 occupancy), > + TP_ARGS(rmid, id, occupancy), > + TP_STRUCT__entry(__field(u32, rmid) > + __field(int, id) > + __field(u64, occupancy)), > + TP_fast_assign(__entry->rmid = rmid; > + __entry->id = id; > + __entry->occupancy = occupancy;), > + TP_printk("rmid=%u domain=%d occupancy=%llu", > + __entry->rmid, __entry->id, __entry->occupancy) > + ); > + Naming is always complicated but I would like to make two proposals with motivation: a) Please prefix this event with "mon_" as the first member of a new "monitor" category of resctrl tracepoints. Users can then interact with monitor tracepoints with convenience of "mon*". Later we could perhaps add a new "alloc*" category. b) Please replace all "rmid" exposure to user space with a more generic "mon_hw_id", or if "mon" is clear, just "hw_id". For reference you can search for "mon_hw_id" in Documentation/arch/x86/resctrl.rst. This is needed because resctrl is in the process of being able to be an interface for Arm's MPAM and "rmid" is an x86 specific term. Considering this, what do you think of something like: tracepoint name: mon_llc_occupancy_limbo print: "mon_hw_id=%u domain=%d llc_occupancy=%llu" > +#endif /* _TRACE_MONITOR_H */ > + > +#undef TRACE_INCLUDE_PATH > +#define TRACE_INCLUDE_PATH . > +#define TRACE_INCLUDE_FILE monitor_event > + > +/* This part must be outside protection */ > +#include <trace/define_trace.h> Thank you. Reinette
On 2024/2/6 03:36, Reinette Chatre wrote: > Hi Haifeng, > > Thank you for proposing this feature. I think it is a useful addition. > I tried it out after removing a monitor group and it was insightful > to be able to see how the cache occupancy of a removed group > shrinks over time. > > On 1/26/2024 5:02 AM, Haifeng Xu wrote: >> If llc_occupany is enabled, the rmid may not be freed immediately unless > > (llc_occupany -> llc_occupancy ... one more instance below) > > Please use caps (RMID) for acronym. > >> its llc_occupany is less than the resctrl_rmid_realloc_threshold. > > I think it will help to highlight that this is related to monitor group > removal. > >> >> In our production environment, those unused rmids get stuck in the limbo >> list forever because their llc_occupancy are larger than the threshold. >> After turning it up, we can successfully free unused rmids and create >> new monitor groups. In order to acquire the llc_occupancy of rmids in >> each rdt domain, we use perf tool to track and filter the log manually. > > Could you please elaborate how you "use perf tool to track and > filter the log manually"? > >> >> It's not efficient enough. Therefore, we can add a new tracepoint that > > "It's not efficient enough." is a vague statement. How was efficiency measured? > and what is "enough"? > > Please do not impersonate code ("we can add a new ...") and stick to the > imperative tone. Please see the "Changelog" section in > Documentation/process/maintainer-tip.rst for more details. > > >> shows the llc_occupancy of busy rmids when scanning the limbo list. It >> can help us to adjust the resctrl_rmid_realloc_threshold to a reasonable >> value. >> >> Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com> >> --- >> arch/x86/kernel/cpu/resctrl/Makefile | 1 + >> arch/x86/kernel/cpu/resctrl/monitor.c | 5 ++++ >> arch/x86/kernel/cpu/resctrl/monitor_event.h | 30 +++++++++++++++++++++ >> 3 files changed, 36 insertions(+) >> create mode 100644 arch/x86/kernel/cpu/resctrl/monitor_event.h >> >> diff --git a/arch/x86/kernel/cpu/resctrl/Makefile b/arch/x86/kernel/cpu/resctrl/Makefile >> index 4a06c37b9cf1..0d3031850d26 100644 >> --- a/arch/x86/kernel/cpu/resctrl/Makefile >> +++ b/arch/x86/kernel/cpu/resctrl/Makefile >> @@ -1,4 +1,5 @@ >> # SPDX-License-Identifier: GPL-2.0 >> obj-$(CONFIG_X86_CPU_RESCTRL) += core.o rdtgroup.o monitor.o >> obj-$(CONFIG_X86_CPU_RESCTRL) += ctrlmondata.o pseudo_lock.o >> +CFLAGS_monitor.o = -I$(src) >> CFLAGS_pseudo_lock.o = -I$(src) > > From what I understand only one of the c files should define CREATE_TRACE_POINTS > and it is that c file that should have its CFLAGS modified. > > I do not think it is necessary to preemptively fragment the resctrl tracing by creating > a separate header file for the monitor tracepoints. This is something that may be > needed as part of current re-design but I think it best to have a simple start that > places all tracepoints in the same header file. > > I would thus like to propose that this work starts by renaming pseudo_lock_event.h > to a more generic (trace.h?) that will contain all the tracepoints. pseudo-lock.c > is the file that define's CREATE_TRACE_POINTS so it should remain as the only > one with its CFLAGS modified. monitor.c should be able to just include "trace.h" > (after "trace.h" is updated with the new tracepoint) without needing to define > CREATE_TRACE_POINTS. > > >> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c >> index f136ac046851..a6f94fcae174 100644 >> --- a/arch/x86/kernel/cpu/resctrl/monitor.c >> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c >> @@ -24,6 +24,10 @@ >> >> #include "internal.h" >> >> +#define CREATE_TRACE_POINTS >> +#include "monitor_event.h" >> +#undef CREATE_TRACE_POINTS >> + >> struct rmid_entry { >> u32 rmid; >> int busy; >> @@ -302,6 +306,7 @@ void __check_limbo(struct rdt_domain *d, bool force_free) >> } >> } >> crmid = nrmid + 1; >> + trace_rmid_llc_occupancy(nrmid, d->id, val); >> } >> } >> >> diff --git a/arch/x86/kernel/cpu/resctrl/monitor_event.h b/arch/x86/kernel/cpu/resctrl/monitor_event.h >> new file mode 100644 >> index 000000000000..91265a2dd2c9 >> --- /dev/null >> +++ b/arch/x86/kernel/cpu/resctrl/monitor_event.h >> @@ -0,0 +1,30 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +#undef TRACE_SYSTEM >> +#define TRACE_SYSTEM resctrl >> + >> +#if !defined(_TRACE_MONITOR_H) || defined(TRACE_HEADER_MULTI_READ) >> +#define _TRACE_MONITOR_H >> + >> +#include <linux/tracepoint.h> >> + >> +TRACE_EVENT(rmid_llc_occupancy, >> + TP_PROTO(u32 rmid, int id, u64 occupancy), >> + TP_ARGS(rmid, id, occupancy), >> + TP_STRUCT__entry(__field(u32, rmid) >> + __field(int, id) >> + __field(u64, occupancy)), >> + TP_fast_assign(__entry->rmid = rmid; >> + __entry->id = id; >> + __entry->occupancy = occupancy;), >> + TP_printk("rmid=%u domain=%d occupancy=%llu", >> + __entry->rmid, __entry->id, __entry->occupancy) >> + ); >> + > > Naming is always complicated but I would like to make two proposals with > motivation: > a) Please prefix this event with "mon_" as the first member of a new > "monitor" category of resctrl tracepoints. Users can then interact > with monitor tracepoints with convenience of "mon*". Later we could > perhaps add a new "alloc*" category. > b) Please replace all "rmid" exposure to user space with a more generic > "mon_hw_id", or if "mon" is clear, just "hw_id". For reference you > can search for "mon_hw_id" in Documentation/arch/x86/resctrl.rst. > This is needed because resctrl is in the process of being able to > be an interface for Arm's MPAM and "rmid" is an x86 specific term. > > Considering this, what do you think of something like: > tracepoint name: mon_llc_occupancy_limbo > print: "mon_hw_id=%u domain=%d llc_occupancy=%llu" > >> +#endif /* _TRACE_MONITOR_H */ >> + >> +#undef TRACE_INCLUDE_PATH >> +#define TRACE_INCLUDE_PATH . >> +#define TRACE_INCLUDE_FILE monitor_event >> + >> +/* This part must be outside protection */ >> +#include <trace/define_trace.h> > > Thank you. > > Reinette Thanks for your suggestions and I'll post a new version later.
diff --git a/arch/x86/kernel/cpu/resctrl/Makefile b/arch/x86/kernel/cpu/resctrl/Makefile index 4a06c37b9cf1..0d3031850d26 100644 --- a/arch/x86/kernel/cpu/resctrl/Makefile +++ b/arch/x86/kernel/cpu/resctrl/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_X86_CPU_RESCTRL) += core.o rdtgroup.o monitor.o obj-$(CONFIG_X86_CPU_RESCTRL) += ctrlmondata.o pseudo_lock.o +CFLAGS_monitor.o = -I$(src) CFLAGS_pseudo_lock.o = -I$(src) diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index f136ac046851..a6f94fcae174 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -24,6 +24,10 @@ #include "internal.h" +#define CREATE_TRACE_POINTS +#include "monitor_event.h" +#undef CREATE_TRACE_POINTS + struct rmid_entry { u32 rmid; int busy; @@ -302,6 +306,7 @@ void __check_limbo(struct rdt_domain *d, bool force_free) } } crmid = nrmid + 1; + trace_rmid_llc_occupancy(nrmid, d->id, val); } } diff --git a/arch/x86/kernel/cpu/resctrl/monitor_event.h b/arch/x86/kernel/cpu/resctrl/monitor_event.h new file mode 100644 index 000000000000..91265a2dd2c9 --- /dev/null +++ b/arch/x86/kernel/cpu/resctrl/monitor_event.h @@ -0,0 +1,30 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM resctrl + +#if !defined(_TRACE_MONITOR_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_MONITOR_H + +#include <linux/tracepoint.h> + +TRACE_EVENT(rmid_llc_occupancy, + TP_PROTO(u32 rmid, int id, u64 occupancy), + TP_ARGS(rmid, id, occupancy), + TP_STRUCT__entry(__field(u32, rmid) + __field(int, id) + __field(u64, occupancy)), + TP_fast_assign(__entry->rmid = rmid; + __entry->id = id; + __entry->occupancy = occupancy;), + TP_printk("rmid=%u domain=%d occupancy=%llu", + __entry->rmid, __entry->id, __entry->occupancy) + ); + +#endif /* _TRACE_MONITOR_H */ + +#undef TRACE_INCLUDE_PATH +#define TRACE_INCLUDE_PATH . +#define TRACE_INCLUDE_FILE monitor_event + +/* This part must be outside protection */ +#include <trace/define_trace.h>