From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D37ED324B2C for ; Wed, 15 Apr 2026 10:51:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776250263; cv=none; b=orqTrPVjbB25AAkAMGzkt/DJyCXR9SZlzdTyVad9cwFI7b5YSHDnR8Pq2h7/B/8ircPzk4zCsMDKCKZ32KdGAZCY2G84IcxQsA+LygHr3Oev+ePkMzg1mXWWzAtRRnPYE3ur1kr4HsrUyNBDylvKOTXf2y9QV9gwUzEyJTUWAYo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776250263; c=relaxed/simple; bh=B58UeNLzLf0f+ZEeYfijTT3sj6ysx0mjzSe2x2ecM0U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NrVkUZNV2wJGhejxXWdZX/vYKumwhsadajyXHhakNUPuM4dcbE/Jl6qYCnY+cnHUZq+OW5TgdUBy9KBoit0dfa8hSDBG5L75KiYJKk603ordUx7zlp4FnIGQZMB8RJ/l/p3zm+x8n1Vnl9isRF0MuYDXm6cetwPgChuW21GBkfI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lvqE819p; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lvqE819p" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-483487335c2so73179915e9.2 for ; Wed, 15 Apr 2026 03:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776250260; x=1776855060; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5Oujqv/8qNyc28E1yGSP7HjqXoiuQysuTJR8y6BvpzU=; b=lvqE819poR3ve1Kac71hdqA9YTPOMmfN3g+HrOQL0ZmJeH5jdQRxpHXx2ihKrG4JvQ 2X15+uJrLCg74KswIvrhIeEzZiaZtguXsGAY2n5GyLlsCq4nIqyR/0f7pEh95wWJmbr4 F5vxq74PlgJMNDp/JlRhRmN+gOW+r8UszdNx2/DvkMwzW5dniYFSia7oGxYyQ0sDOO+/ KOO79ezlGiS6j4JQhxfV0cOKy09a/rxzkFTUUPRF97A9NU9ih6MIZlcbEmih03O3E4gR 6TOKuEUaoovDQGlQEJGils5bjqqgsfSKcjc8lZpftKCbNrUwVxb53TyLxm6oBt365BIc bY+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776250260; x=1776855060; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5Oujqv/8qNyc28E1yGSP7HjqXoiuQysuTJR8y6BvpzU=; b=LKhsq+bLPqsuWX+N25PBdJrK5GUhTpXkG4pLWrprc+ZdBYf9sxQqsnDXkvneU8UfRt +D8G1iC7kMCDKln9bSWX7SahudOk+w3rNo70jMmc8914EuZdJqlyh6lpT76WVvEbovsQ Fe+EYntAvB2m60oLBwLT7eGlDyMgoIiXCFG6UJw+m720dfqvMJzrr8nDdsyjAOPnRmem 3HmC8OIlHzkcbVAUSOd1NsDS0F0ZoQ7uqrTxWiwLjAdg5rfensi2+6A/yIKz3LO8d2cG IVKey1+PelpGaBfMXl2Pj1wV5zYoBx6EGshJgQ5l3hxen8ulLCQKWRJ8nWuhbdXevIl0 Uw2w== X-Forwarded-Encrypted: i=1; AFNElJ8vMt/y1WVfDl/l7UtWrBu8/8Wn1dwCivEeadKMnvmlZ0FqOraE9w4987/U5ZYoHjNlMAqntKvYE91cq0Y=@vger.kernel.org X-Gm-Message-State: AOJu0YyOEpFHhf65uY5I5c99FRwaIc9vNdxS2odJMloEPdLFAo5ZHkcL ln9Z8OuFLy3/WQHqXG4zlvPHg5RiYQgBzDD+LGV4eX4+1L9MSECO+N08 X-Gm-Gg: AeBDietM3C9LTWWwXg0U3l3B7Gso67xXtbQCE/B+3ENudS7yLpHmWi+KVWp4vkqlL5c o7kym4eI/SdTaTPrbRt6WAM9xs2/KCKt4gyOeyBccaPzG3zLfFZVLJS2A73V5BzGpU6U4IUmD/c lOA2c3UgmtheC7E3vVgnw7BEIEbLl7WE5fUZLA6Ez30iD3vI4YFkU4Yxcp/VO+wEgpVoBS64ZjY qJEs1t3G67uZSopl1zBHXQEBLlPsLukbXxQ9hIycEAUw72DIsPsPMx+AnxypEuK6pcmQ3bfVqcZ 5iu+Zq8WZULb+fxRwD6hEfpwHtqWkpOR9RFL/KzlBw12rLqcU8uDbq39/gTjs/iOsMCVKlkSijY v8ledSWc8HVYujS9OvUoR1Ake45Lf5Vumu8EZjrJ3OF3B9seQUNkZDKpEzei1tjGv7/xg5yz50S 1QIqZ7MoYKCVhIgxCFCAAwkVPDzgeXIztVr56N8BAlBXWrVYW2MVaZTnVHlqznrNylm5BQ90q28 62ryNzBTjlKddRkr7HW28KsiaY= X-Received: by 2002:a05:600c:a109:b0:488:b239:77ec with SMTP id 5b1f17b1804b1-488d683d510mr208028525e9.17.1776250260014; Wed, 15 Apr 2026 03:51:00 -0700 (PDT) Received: from [192.168.1.191] (host-2-101-228-96.as13285.net. [2.101.228.96]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488f1deb9besm41283005e9.6.2026.04.15.03.50.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 03:50:59 -0700 (PDT) Message-ID: <2a94d80f-a148-47b3-8373-b7a38ff8b9f4@gmail.com> Date: Wed, 15 Apr 2026 11:50:58 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drm/xe/bo: Cache vram_region_gpu_offset in struct xe_bo To: Matthew Brost , Yuri Martins Cc: =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , "intel-xe@lists.freedesktop.org" , Rodrigo Vivi , David Airlie , Simona Vetter , Matthew Auld , Matt Roper , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" References: <10289571cccff20ba52f224080754705c606ccfe.camel@linux.intel.com> Content-Language: en-US From: Yicong Hui In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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