Messages in this thread | | | Date | Tue, 17 May 2022 14:23:38 -0700 | Subject | Re: [PATCH v4 19/21] x86/resctrl: Rename and change the units of resctrl_cqm_threshold | From | Reinette Chatre <> |
| |
Hi James,
On 4/12/2022 5:44 AM, James Morse wrote: > resctrl_cqm_threshold is stored in a hardware specific chunk size, > but exposed to user-space as bytes. > > This means the filesystem parts of resctrl need to know how the hardware > counts, to convert the user provided byte value to chunks. The interface > between the architecture's resctrl code and the filesystem ought to > treat everything as bytes. > > Change the unit of resctrl_cqm_threshold to bytes. resctrl_arch_rmid_read() > still returns its value in chunks, so this needs converting to bytes. > As all the users have been touched, rename the variable to > resctrl_rmid_realloc_threshold, which describes what the value is for. > > Neither r->num_rmid nor hw_res->mon_scale are guaranteed to be a power > of 2, so the existing code introduces a rounding error from resctrl's > theoretical fraction of the cache usage. This behaviour is kept as it > ensures the user visible value matches the value read from hardware > when the rmid will be reallocated.
The goal mentioned above does not seem to match the changes made to the code parsing the user provided value ...
...
> @@ -1066,8 +1062,7 @@ static ssize_t max_threshold_occ_write(struct kernfs_open_file *of, > if (bytes > (boot_cpu_data.x86_cache_size * 1024)) > return -EINVAL; > > - hw_res = resctrl_to_arch_res(of->kn->parent->priv); > - resctrl_cqm_threshold = bytes / hw_res->mon_scale; > + resctrl_rmid_realloc_threshold = bytes; > > return nbytes; > }
... originally resctrl_cqm_threshold would take user provided value and adjust it to the mon_scale but in this change the bytes provided by user space is kept as-is and would thus no longer match what can be read from hardware.
Reinette
| |