Re: [PATCH] drm/xe/bo: Cache vram_region_gpu_offset in struct xe_bo
From: Yicong Hui
Date: Wed Apr 15 2026 - 06:52:12 EST
On 01/04/2026 04:52, Matthew Brost wrote:
On Wed, Apr 01, 2026 at 02:53:17AM +0000, Yuri Martins wrote:Hi Matthew,
Hi Thomas,All good — we should probably just delete this XXX, as it was an early
Thanks for the review and the detailed feedback on the move_notify pattern.
You're right to ask for performance data, I don't have any. My hardware
(Core Ultra 7 258V) is integrated-only, so vram_region_gpu_offset() returns
0 and the path this targets was never exercised. I should have realized
that before submitting.
comment from me back when I still had the i915 micro-optimization
mindset. I agree with Thomas that a change like this has little to no
impact, given that binds (where this code is typically used) are orders
of magnitude slower than clearing or moving memory. Plus, binds really
only end up in the critical path during page faults — and even there,
we’re usually moving memory first, so a little pointer chasing isn’t
going to show up.
As someone who has done quite a bit of perf work, here are the areas we
should focus on cleaning up:
- Time-complexity reduction (e.g., if we can go from O(N²) to O(N log N),
etc.)
- Reduce unnecessary context switches (e.g., don’t call queue_work()
blindly when it has nothing to do)
- Memory placement improvements (e.g., move CPU-read buffers to system
memory; move GPU-read buffers to VRAM)
- Use the hardware correctly (e.g., reduce GPU context switches for
common kernel operations, etc.)
Matt
Withdrawing this patch.
Thanks,
Yuri
I'm new to kernel development, and I was reading mailing list archives and was interested by your comment - I want to try exploring your suggestions for performance-improvement patches, particularly in reducing time complexity. Do you know of any areas of code within the xe drivers that I could potentially try to work on? My personal machine runs a Core Ultra processor.
Thank you for your time!
Yicong