lkml.org 
[lkml]   [2024]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v1 1/6] x86/resctrl: Move __resctrl_sched_in() out-of-line
From
Hi Peter,

On 4/8/2024 12:05 PM, Peter Newman wrote:
> Hi Reinette,
>
> On Sun, Apr 7, 2024 at 12:21 PM Reinette Chatre
> <reinette.chatre@intel.com> wrote:
>>
>> I think this needs more thought. rdt_enable_key is x86 specific now and should not
>> be in the fs code. Every architecture will have its own task switch code, with
>> __resctrl_sched_in() belonging to x86 and thus not something to be directly called
>> from the fs code.
>
> I think we will need to discuss whether __resctrl_sched_in() is really
> arch or FS code following the changes in this series. This series
> removes the explicit MSR access and James has already provided inline

Indeed, I missed how resctrl_arch_update_cpu() introduced in
"x86/resctrl: Abstract PQR_ASSOC from generic code" results in
__resctrl_sched_in() being architecture agnostic.

(sidenotes ... it is not obvious to me why resctrl_arch_update_cpu()
is not consistently used, for example, in clear_closid_rmid(),
and it also seems a better candidate to be inline within
arch/x86/include/asm/resctrl.h)

> wrappers for the mon and alloc enable keys[1], so I can only assume
> they are architecture-independent in concept.

The wrappers are intended to be architecture-independent, but the keys
are architecture dependent. Quoting the commit you linked to:
"This means other architectures don't have to mirror the static keys"

Reinette

> https://lore.kernel.org/r/20240213184438.16675-18-james.morse@arm.com

\
 
 \ /
  Last update: 2024-05-27 16:30    [W:0.168 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site