[PATCH v11 2/4] drm/xe: Add locks in gtidle code
Lucas De Marchi
lucas.demarchi at intel.com
Fri Dec 20 22:09:30 UTC 2024
On Fri, Dec 20, 2024 at 01:15:07PM -0800, Belgaumkar, Vinay wrote:
>
>On 12/20/2024 1:09 PM, Matthew Brost wrote:
>>On Fri, Dec 20, 2024 at 12:59:25PM -0800, Vinay Belgaumkar wrote:
>>>Another entry point is added so PMU code can call into the gtidle
>>>method for residency. Add locking so that parallel calls to this
>>>method from sysfs and PMU don't give inconsistent gtidle states
>>>for c6 residency.
>>>
>>>Suggested-by: Lucas De Marchi <lucas.demarchi at intel.com>
>>>Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
>>>Cc: Lucas De Marchi <lucas.demarchi at intel.com>
>>>Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
>>>---
>>> drivers/gpu/drm/xe/xe_gt_idle.c | 23 ++++++++++++++++++++---
>>> drivers/gpu/drm/xe/xe_gt_idle.h | 1 +
>>> drivers/gpu/drm/xe/xe_gt_idle_types.h | 3 +++
>>> 3 files changed, 24 insertions(+), 3 deletions(-)
>>>
>>>diff --git a/drivers/gpu/drm/xe/xe_gt_idle.c b/drivers/gpu/drm/xe/xe_gt_idle.c
>>>index fd80afeef56a..1f32ac964abe 100644
>>>--- a/drivers/gpu/drm/xe/xe_gt_idle.c
>>>+++ b/drivers/gpu/drm/xe/xe_gt_idle.c
>>>@@ -69,6 +69,8 @@ static u64 get_residency_ms(struct xe_gt_idle *gtidle, u64 cur_residency)
>>> {
>>> u64 delta, overflow_residency, prev_residency;
>>>+ lockdep_assert_held(>idle->lock);
>>>+
>>> overflow_residency = BIT_ULL(32);
>>> /*
>>>@@ -273,8 +275,21 @@ static ssize_t idle_status_show(struct device *dev,
>>> return sysfs_emit(buff, "%s\n", gt_idle_state_to_string(state));
>>> }
>>>-static DEVICE_ATTR_RO(idle_status);
>>>+u64 xe_gt_idle_residency_msec(struct xe_gt_idle *gtidle)
>>>+{
>>>+ struct xe_guc_pc *pc = gtidle_to_pc(gtidle);
>>>+ u64 residency;
>>>+ unsigned long flags;
>>>+
>>>+ raw_spin_lock_irqsave(>idle->lock, flags);
>>Why raw spin lock rather than just spin lock?
>
>Lucas suggested this as the perf subsystem uses raw_spinlocks, so we
>cannot use spinlocks when the perf calls into Xe.
correct. Any entrypoint via perf may be via a hardirq and always use a
raw_spinlock. All the other PMUs I could find (except i915, that is
wrong) use raw_spinlock
More info:
https://lore.kernel.org/intel-xe/20241212093123.GV21636@noisy.programming.kicks-ass.net/
Alternative is to have a worker where the actual read happens and make
the perf entrypoint to read that value from memory. But then that value
will need to be protected via a raw_spinlock anyway.
Lucas De Marchi
More information about the Intel-xe
mailing list