On 2023-01-31 14:16:48 [+0100], Richard Weinberger wrote:
> Hi,
Hi!,
> A reliable trigger for the problem is using the Chromium browser when
> it utilizes OpenGL.
need to try that. OpenGL as in watching a video with HW acceleration
enabled or is there something else?
> The root of the problem seems to be that struct intel_uncore->lock is
> a regular spinlock but
> taken in atomic context.
> AFAICT the atomic context is a result of kmap_atomic() and
> io_mapping_map_atomic_wc()
kmap_atomic() should be fine as it does not disable preemption.
io_mapping_map_atomic_wc() on the other hand does disable preemption.
Now looking at this, it seems to happen eb_relocate_vma(). From staring
at it, you might be lucky to get away with
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index 09d4f17c8d3b6..5ddc70a4e7e3e 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -162,7 +162,7 @@ static inline void __iomem *
io_mapping_map_atomic_wc(struct io_mapping *mapping,
unsigned long offset)
{
- preempt_disable();
+ migrate_disable();
pagefault_disable();
return io_mapping_map_wc(mapping, offset, PAGE_SIZE);
}
@@ -172,7 +172,7 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
{
io_mapping_unmap(vaddr);
pagefault_enable();
- preempt_enable();
+ migrate_enable();
}
static inline void __iomem *
which is based on 6.2 but you get the idea.
> usage in i915.
> Converting the said lock to a raw spinlock cures the problem but the
> overall latency almost doubles.
yeah. I tried that once, too.
> I'm pretty sure the problem exists also on v6.2-rc3-rt1 because there
> the affected lock is also
> still a spinlock and used below kmap_atomic() and io_mapping_map_atomic_wc().
Could you please try the hack above and check if it appears to work?
Sebastian
