>> So fgets( ...) followed with "if (offline_cpus_str[0] == '\n') "?
>
> How about simplifying it more to "if (fgetc(fp) == '\n')" ?
Reinette,
Even better.
-Tony
+static bool cpus_offline_empty(void)
+{
+ char offline_cpus_str[64];
+ FILE *fp;
+
+ fp = fopen("/sys/devices/system/cpu/offline", "r");
Check for fp == NULL before using it.
+ if (fscanf(fp, "%s", offline_cpus_str) < 0) {
fscanf() seems like a heavy hammer.
if
> >>> When SNC mode is enabled the effective amount of L3 cache available
> >>> for allocation is divided by the number of nodes per L3.
> >>
> >> This was a mistake in original implementation and no longer done.
> >
> > My original kernel code adjusted value reported in the "size" file in
> > res
>> When SNC mode is enabled the effective amount of L3 cache available
>> for allocation is divided by the number of nodes per L3.
>
> This was a mistake in original implementation and no longer done.
My original kernel code adjusted value reported in the "size" file in resctrl.
That's no longer d
If/when my SNC patches go upstream the SNC check could become:
snc_ways=$(ls -d /sys/fs/resctrl/mon_data/mon_L3_00/mon_sub_L3_* 2>/dev/null |
wc -l)
assuming you have /sys/fs/resctrl mounted.
-Tony
> Could you please help me understand the details by answering my first
> question: What is the use case for needing to expose the individual cluster
> counts?
>
> This is a model specific feature so if this is something needed for just a
> couple of systems I think we should be less inclined to m
> Perhaps ... in this case it may make things easier to understand if
> those "mon_NODE_*" directories are sub-directories of the appropriate
> "mon_L3_*" directories.
Reinette,
Like this?
$ tree mon_data/
mon_data/
├── mon_L3_00
│ ├── llc_occupancy
│ ├── mbm_local_bytes
│ ├── mbm_total_b
> > What is the use case for needing to expose the individual cluster counts?
> > What if
> > resctrl just summed the cluster counts and presented the data as before -
> > per L3
> > cache instance? I doubt that resctrl would be what applications would use
> > to verify
> > whether they are "wel
> What is the use case for needing to expose the individual cluster counts?
> What if
> resctrl just summed the cluster counts and presented the data as before - per
> L3
> cache instance? I doubt that resctrl would be what applications would use to
> verify
> whether they are "well behaved" wrt
> >> While that is in some ways a more accurate view, it breaks a lot of
> >> legacy monitoring applications that expect the "L3" names.
> >
> > True - but the behaviour is different from a non SNC system, if this
> > software can read the
> > file - but goes wrong because the contents of the file
> Thinking about it even differently. The goal is to give information
> to userspace so we need to think about what would help user space?
> For example, what if there is a file in info that shows
> which CPUs are associated with each domain?
Reinette,
Interesting idea. That would save users fro
> > SNC2 enabled:
> >
> > $ cat /sys/fs/resctrl/info/L3_mon/ snc_nodes_per_l3_cache
> > 2
> >
>
> This would be useful. I believe "SNC" is architecture specific?
> What if the file always exists and is named "nodes_per_l3_cache"?
>
> I assume that the internals of handling more nodes per L3 cache s
>>If so, what should it be named? "snc_ways" as a kernel variable was
>>later replaced by "snc_nodes_per_l3_cache". Is that a good filename?
>
> "snc_nodes_per_l3_cache" seems okay to me.
>
> And I understand that the file content would show SNC mode and the presence or
> absence of this file would
> Figuring out if SNC is enabled is only one part of the problem, the
> other being whether the kernel supports it. As there is no easy
> interface that simply states SNC support in the kernel one can find that
> information by comparing L3 cache sizes from different sources. Cache
> size reported
14 matches
Mail list logo
