After removing a monitor group, its RMID may not be freed immediately
unless its llc_occupancy is less than the re-allocation threshold. If
turning up the threshold, the RMID can be reused. In order to know how
much the threshold should be, it's necessary to acquire the llc_occupancy.
The patch series provides a new tracepoint to track the llc_occupancy.
Changes since v1:
- Rename pseudo_lock_event.h instead of creating a new header file.
- Modify names used in the tracepoint.
- Update changelog.
Changes since v2:
- Fix typo and use the x86/resctrl subject prefix in the cover letter.
- Track both CLOSID and RMID in the tracepoint.
- Remove the details on how perf can be used in patch2's changelog.
Changes since v3:
- Put the tracepoint in the 'else' section of the if/else after
resctrl_arch_rmid_read().
- Modify names used in the tracepoint.
- Document the properties of the tracepoint.
Changes since v4:
- Add Reviewed-by tags.
- Include more maintainers in the submission.
Changes since v5:
- Update the documentation and comments of the tracepoint.
- Code cleanup.
Haifeng Xu (2):
x86/resctrl: Rename pseudo_lock_event.h to trace.h
x86/resctrl: Add tracepoint for llc_occupancy tracking
Documentation/arch/x86/resctrl.rst | 6 +++++
arch/x86/kernel/cpu/resctrl/monitor.c | 11 +++++++++
arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 2 +-
.../resctrl/{pseudo_lock_event.h => trace.h} | 24 +++++++++++++++----
4 files changed, 38 insertions(+), 5 deletions(-)
rename arch/x86/kernel/cpu/resctrl/{pseudo_lock_event.h => trace.h} (56%)
--
2.25.1
Now only pseudo-locking part uses tracepoints to do event tracking, but
other parts of resctrl may need new tracepoints. It is unnecessary to
create separate header files and define CREATE_TRACE_POINTS in different
c files which fragments the resctrl tracing.
Therefore, give the resctrl tracepoint header file a generic name to
support its use for tracepoints that are not specific to pseudo-locking.
No functional change.
Signed-off-by: Haifeng Xu <[email protected]>
Suggested-by: Reinette Chatre <[email protected]>
---
arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 2 +-
.../kernel/cpu/resctrl/{pseudo_lock_event.h => trace.h} | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
rename arch/x86/kernel/cpu/resctrl/{pseudo_lock_event.h => trace.h} (86%)
diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
index 884b88e25141..492c8e28c4ce 100644
--- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
+++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
@@ -31,7 +31,7 @@
#include "internal.h"
#define CREATE_TRACE_POINTS
-#include "pseudo_lock_event.h"
+#include "trace.h"
/*
* The bits needed to disable hardware prefetching varies based on the
diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock_event.h b/arch/x86/kernel/cpu/resctrl/trace.h
similarity index 86%
rename from arch/x86/kernel/cpu/resctrl/pseudo_lock_event.h
rename to arch/x86/kernel/cpu/resctrl/trace.h
index 428ebbd4270b..495fb90c8572 100644
--- a/arch/x86/kernel/cpu/resctrl/pseudo_lock_event.h
+++ b/arch/x86/kernel/cpu/resctrl/trace.h
@@ -2,8 +2,8 @@
#undef TRACE_SYSTEM
#define TRACE_SYSTEM resctrl
-#if !defined(_TRACE_PSEUDO_LOCK_H) || defined(TRACE_HEADER_MULTI_READ)
-#define _TRACE_PSEUDO_LOCK_H
+#if !defined(_TRACE_RESCTRL_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_RESCTRL_H
#include <linux/tracepoint.h>
@@ -35,9 +35,9 @@ TRACE_EVENT(pseudo_lock_l3,
TP_printk("hits=%llu miss=%llu",
__entry->l3_hits, __entry->l3_miss));
-#endif /* _TRACE_PSEUDO_LOCK_H */
+#endif /* _TRACE_RESCTRL_H */
#undef TRACE_INCLUDE_PATH
#define TRACE_INCLUDE_PATH .
-#define TRACE_INCLUDE_FILE pseudo_lock_event
+#define TRACE_INCLUDE_FILE trace
#include <trace/define_trace.h>
--
2.25.1
In our production environment, after removing monitor groups, those unused
RMIDs get stuck in the limbo list forever because their llc_occupancy are
always larger than the threshold. But the unused RMIDs can be successfully
freed by turning up the threshold.
In order to know how much the threshold should be, perf can be used to
acquire the llc_occupancy of RMIDs in each rdt domain.
Instead of using perf tool to track llc_occupancy and filter the log
manually, it is more convenient for users to use tracepoint to do this
work. So add a new tracepoint that shows the llc_occupancy of busy RMIDs
when scanning the limbo list.
Signed-off-by: Haifeng Xu <[email protected]>
Suggested-by: Reinette Chatre <[email protected]>
Suggested-by: James Morse <[email protected]>
Reviewed-by: James Morse <[email protected]>
---
Documentation/arch/x86/resctrl.rst | 6 ++++++
arch/x86/kernel/cpu/resctrl/monitor.c | 11 +++++++++++
arch/x86/kernel/cpu/resctrl/trace.h | 16 ++++++++++++++++
3 files changed, 33 insertions(+)
diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst
index a6279df64a9d..bcdbd23cd8a7 100644
--- a/Documentation/arch/x86/resctrl.rst
+++ b/Documentation/arch/x86/resctrl.rst
@@ -446,6 +446,12 @@ during mkdir.
max_threshold_occupancy is a user configurable value to determine the
occupancy at which an RMID can be freed.
+The mon_llc_occupancy_limbo tracepoint gives the precise occupancy in bytes
+for a subset of RMID that are not immediately available for allocation.
+This can't be relied on to produce output every second, it may be necessary
+to attempt to create an empty monitor group to force an update. Output may
+only be produced if creation of a control or monitor group fails.
+
Schemata files - general concepts
---------------------------------
Each line in the file describes one resource. The line starts with
diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
index c34a35ec0f03..2345e6836593 100644
--- a/arch/x86/kernel/cpu/resctrl/monitor.c
+++ b/arch/x86/kernel/cpu/resctrl/monitor.c
@@ -24,6 +24,7 @@
#include <asm/resctrl.h>
#include "internal.h"
+#include "trace.h"
/**
* struct rmid_entry - dirty tracking for all RMID.
@@ -354,6 +355,16 @@ void __check_limbo(struct rdt_domain *d, bool force_free)
rmid_dirty = true;
} else {
rmid_dirty = (val >= resctrl_rmid_realloc_threshold);
+
+ /*
+ * x86's CLOSID and RMID are independent numbers, so the entry's
+ * CLOSID is an empty CLOSID (X86_RESCTRL_EMPTY_CLOSID). On Arm the
+ * RMID (PMG) extends the CLOSID (PARTID) space with bits that aren't
+ * used to select the configuration. It is thus necessary to track both
+ * CLOSID and RMID because there may be dependencies between them
+ * on some architectures.
+ */
+ trace_mon_llc_occupancy_limbo(entry->closid, entry->rmid, d->id, val);
}
if (force_free || !rmid_dirty) {
diff --git a/arch/x86/kernel/cpu/resctrl/trace.h b/arch/x86/kernel/cpu/resctrl/trace.h
index 495fb90c8572..2a506316b303 100644
--- a/arch/x86/kernel/cpu/resctrl/trace.h
+++ b/arch/x86/kernel/cpu/resctrl/trace.h
@@ -35,6 +35,22 @@ TRACE_EVENT(pseudo_lock_l3,
TP_printk("hits=%llu miss=%llu",
__entry->l3_hits, __entry->l3_miss));
+TRACE_EVENT(mon_llc_occupancy_limbo,
+ TP_PROTO(u32 ctrl_hw_id, u32 mon_hw_id, int domain_id, u64 llc_occupancy_bytes),
+ TP_ARGS(ctrl_hw_id, mon_hw_id, domain_id, llc_occupancy_bytes),
+ TP_STRUCT__entry(__field(u32, ctrl_hw_id)
+ __field(u32, mon_hw_id)
+ __field(int, domain_id)
+ __field(u64, llc_occupancy_bytes)),
+ TP_fast_assign(__entry->ctrl_hw_id = ctrl_hw_id;
+ __entry->mon_hw_id = mon_hw_id;
+ __entry->domain_id = domain_id;
+ __entry->llc_occupancy_bytes = llc_occupancy_bytes;),
+ TP_printk("ctrl_hw_id=%u mon_hw_id=%u domain_id=%d llc_occupancy_bytes=%llu",
+ __entry->ctrl_hw_id, __entry->mon_hw_id, __entry->domain_id,
+ __entry->llc_occupancy_bytes)
+ );
+
#endif /* _TRACE_RESCTRL_H */
#undef TRACE_INCLUDE_PATH
--
2.25.1
Hi Haifeng,
On 3/19/2024 1:30 AM, Haifeng Xu wrote:
> After removing a monitor group, its RMID may not be freed immediately
> unless its llc_occupancy is less than the re-allocation threshold. If
> turning up the threshold, the RMID can be reused. In order to know how
> much the threshold should be, it's necessary to acquire the llc_occupancy.
>
> The patch series provides a new tracepoint to track the llc_occupancy.
There seems to be a problem with the DKIM attestation. Here is what I see
when I download this series:
$ b4 am -Q [email protected]
Grabbing thread from lore.kernel.org/all/[email protected]/t.mbox.gz
Analyzing 3 messages in the thread
Looking for additional code-review trailers on lore.kernel.org
Checking attestation on all messages, may take a moment...
---
✗ [PATCH v6 1/2] x86/resctrl: Rename pseudo_lock_event.h to trace.h
✗ [PATCH v6 2/2] x86/resctrl: Add tracepoint for llc_occupancy tracking
---
✗ BADSIG: DKIM/shopee.com
---
Total patches: 2
---
The patches look good to me. Thank you very much for adding this.
Please resubmit with the DKIM attestation fixed and then you can add:
| Reviewed-by: Reinette Chatre <[email protected]>
Reinette
On 2024/3/30 07:06, Reinette Chatre wrote:
> Hi Haifeng,
>
> On 3/19/2024 1:30 AM, Haifeng Xu wrote:
>> After removing a monitor group, its RMID may not be freed immediately
>> unless its llc_occupancy is less than the re-allocation threshold. If
>> turning up the threshold, the RMID can be reused. In order to know how
>> much the threshold should be, it's necessary to acquire the llc_occupancy.
>>
>> The patch series provides a new tracepoint to track the llc_occupancy.
>
> There seems to be a problem with the DKIM attestation. Here is what I see
> when I download this series:
>
> $ b4 am -Q [email protected]
> Grabbing thread from lore.kernel.org/all/[email protected]/t.mbox.gz
> Analyzing 3 messages in the thread
> Looking for additional code-review trailers on lore.kernel.org
> Checking attestation on all messages, may take a moment...
> ---
> ✗ [PATCH v6 1/2] x86/resctrl: Rename pseudo_lock_event.h to trace.h
> ✗ [PATCH v6 2/2] x86/resctrl: Add tracepoint for llc_occupancy tracking
> ---
> ✗ BADSIG: DKIM/shopee.com
> ---
> Total patches: 2
> ---
>
Hi, Reinette,
I can also reproduced it. After digging into it, I found that our DKIM signature header
has 't' and 'x' flags. They are recommended as a means to help identify spam.
t= is the DKIM signature timestamp.
x= is the DKIM signature expiration time.
The source code of DKIM Validation can be seen in dkim/__init__.py(line 351), I paste it
here.
343 if b'x' in sig:
344 if re.match(br"\d+$", sig[b'x']) is None:
345 raise ValidationError(
346 "x= value is not a decimal integer (%s)" % sig[b'x'])
347 x_sign = int(sig[b'x'])
348 now = int(time.time())
349 slop = 36000 # 10H leeway for mailers with inaccurate clocks
350 if x_sign < now - slop:
351 raise ValidationError(
352 "x= value is past (%s)" % sig[b'x'])
353 if x_sign < t_sign:
354 raise ValidationError(
355 "x= value is less than t= value (x=%s t=%s)" %
356 (sig[b'x'], sig[b't']))
The expiry time is less than the time point you download the patch, so the validation
fails. If I comment out these lines, this series can be successfully downloaded.
The signature is only valid for a week. So if you use b4 to download the patch series,
It's best to do it in a week after the patch is sent.
Thanks.
> The patches look good to me. Thank you very much for adding this.
> Please resubmit with the DKIM attestation fixed and then you can add:
>
> | Reviewed-by: Reinette Chatre <[email protected]>
>
> Reinette
Thanks for your review.
On Mon, Apr 08, 2024 at 03:44:00PM +0800, Haifeng Xu wrote:
> I can also reproduced it. After digging into it, I found that our DKIM signature header
> has 't' and 'x' flags. They are recommended as a means to help identify spam.
>
> t= is the DKIM signature timestamp.
> x= is the DKIM signature expiration time.
>
> The source code of DKIM Validation can be seen in dkim/__init__.py(line 351), I paste it
> here.
>
> 343 if b'x' in sig:
> 344 if re.match(br"\d+$", sig[b'x']) is None:
> 345 raise ValidationError(
> 346 "x= value is not a decimal integer (%s)" % sig[b'x'])
> 347 x_sign = int(sig[b'x'])
> 348 now = int(time.time())
> 349 slop = 36000 # 10H leeway for mailers with inaccurate clocks
> 350 if x_sign < now - slop:
> 351 raise ValidationError(
> 352 "x= value is past (%s)" % sig[b'x'])
> 353 if x_sign < t_sign:
> 354 raise ValidationError(
> 355 "x= value is less than t= value (x=%s t=%s)" %
> 356 (sig[b'x'], sig[b't']))
>
> The expiry time is less than the time point you download the patch, so the validation
> fails. If I comment out these lines, this series can be successfully downloaded.
FWIW, I've requested ability to ignore the x= flag when validating signatures:
https://bugs.launchpad.net/dkimpy/+bug/2047054
-K
On 4/8/2024 8:29 AM, Konstantin Ryabitsev wrote:
> On Mon, Apr 08, 2024 at 03:44:00PM +0800, Haifeng Xu wrote:
>> I can also reproduced it. After digging into it, I found that our DKIM signature header
>> has 't' and 'x' flags. They are recommended as a means to help identify spam.
>>
>> t= is the DKIM signature timestamp.
>> x= is the DKIM signature expiration time.
>>
>> The source code of DKIM Validation can be seen in dkim/__init__.py(line 351), I paste it
>> here.
>>
>> 343 if b'x' in sig:
>> 344 if re.match(br"\d+$", sig[b'x']) is None:
>> 345 raise ValidationError(
>> 346 "x= value is not a decimal integer (%s)" % sig[b'x'])
>> 347 x_sign = int(sig[b'x'])
>> 348 now = int(time.time())
>> 349 slop = 36000 # 10H leeway for mailers with inaccurate clocks
>> 350 if x_sign < now - slop:
>> 351 raise ValidationError(
>> 352 "x= value is past (%s)" % sig[b'x'])
>> 353 if x_sign < t_sign:
>> 354 raise ValidationError(
>> 355 "x= value is less than t= value (x=%s t=%s)" %
>> 356 (sig[b'x'], sig[b't']))
>>
>> The expiry time is less than the time point you download the patch, so the validation
>> fails. If I comment out these lines, this series can be successfully downloaded.
>
> FWIW, I've requested ability to ignore the x= flag when validating signatures:
> https://bugs.launchpad.net/dkimpy/+bug/2047054
Thank you very much Haifeng and Konstantin.
Reinette