From: Yicong Hui <yiconghui@gmail.com>
To: Matthew Brost <matthew.brost@intel.com>,
Yuri Martins <yurimartins2004@hotmail.com>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Matthew Auld" <matthew.auld@intel.com>,
"Matt Roper" <matthew.d.roper@intel.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/xe/bo: Cache vram_region_gpu_offset in struct xe_bo
Date: Wed, 15 Apr 2026 11:50:58 +0100 [thread overview]
Message-ID: <2a94d80f-a148-47b3-8373-b7a38ff8b9f4@gmail.com> (raw)
In-Reply-To: <acyWeZ+n2D8wE1cd@gsse-cloud1.jf.intel.com>
On 01/04/2026 04:52, Matthew Brost wrote:
> On Wed, Apr 01, 2026 at 02:53:17AM +0000, Yuri Martins wrote:
>> Hi Thomas,
>>
>> 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.
> All good — we should probably just delete this XXX, as it was an early
> 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
Hi Matthew,
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
prev parent reply other threads:[~2026-04-15 10:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-29 22:22 Yuri Martins
2026-03-30 8:02 ` Thomas Hellström
2026-04-01 2:53 ` Yuri Martins
2026-04-01 3:52 ` Matthew Brost
2026-04-15 10:50 ` Yicong Hui [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2a94d80f-a148-47b3-8373-b7a38ff8b9f4@gmail.com \
--to=yiconghui@gmail.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
--cc=yurimartins2004@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®