From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7918E23E342 for ; Sat, 11 Jul 2026 02:56:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783738588; cv=none; b=gCiaE57hxOheU+pv9nWYWYjEzcJe4BTFqPa2i98ocarigrAPDG/qcatIxPbmWgIx227i+hSA8eAJxZk1YzTRwARWE+KZxpPjwr84PjCzShI3gS7SXuYv3tU+ZdUq7UyM4Vp+X1E+X6SXPB7IBqyC4+bO9eCdd/4ZBZ0EgHTNubc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783738588; c=relaxed/simple; bh=mmFrx4Dja2D4OA3tWnljR27NvP7JQWDMKwyqsxVk7n4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=LLys68p4HcIaFG/xzF5Jv/j4lEE4xxAN2WOvnZ+BmotY6+pk4aeAI1t39XCRYW5vHeJqiGkkVQkAnBl8mthNMdBGDhXC3G7ekgUAndIBvCRbh9MPIrBRgarybZiG2lJ8+4hwl8LJ6OB0wEGRJ3WO9ntKbMHl10E8cQ0usnruY1Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MjbsOyH/; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MjbsOyH/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1783738587; x=1815274587; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=mmFrx4Dja2D4OA3tWnljR27NvP7JQWDMKwyqsxVk7n4=; b=MjbsOyH/0y4BPqDnauv+zsNA0nnzbYDxNclpb3L6MH8oVPIM5YhoHxA5 GbndYr/kvDBcKbN7DbYftqzVzMV0heyTbg3ZIR3mMp98exXSU8ooUro7H ImrbZdcFSew9PPKPgUP3gyBTLZnYURU61YTd4lzb5oNCAqxLPAt0EywEH XNFwtQwr6WPR7gR5IanZP563WHm05nXrDklfNdjuooh9VQy2hJgu5TZvH Nu6Z5TuU/sAFgahA3qa/6ya6hIZhhsiM+tOjgnUR1Ly8CJNxYg8nsQnhZ fNF9ls5rNj6dnf9s8QVhD9X4bCRIYHgGHr+HJ/c9pACLUxuykU6YU4ouI g==; X-CSE-ConnectionGUID: dRqBPD0oRL+CwLSQokWdoQ== X-CSE-MsgGUID: fRa73RdES0CdlIGlfpd1qg== X-IronPort-AV: E=McAfee;i="6800,10657,11841"; a="101986177" X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="101986177" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2026 19:56:25 -0700 X-CSE-ConnectionGUID: wuxuNC8+SWGV8q3yE5Qw6w== X-CSE-MsgGUID: WB3Q9LK3Q2Wfi7vS+cA02g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="256987676" Received: from gsse-cloud1.jf.intel.com ([10.54.39.91]) by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2026 19:56:24 -0700 From: Matthew Brost To: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: Carlos Santa , Ryan Neph , Christian Koenig , Huang Rui , Matthew Auld , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , linux-kernel@vger.kernel.org, =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= Subject: [PATCH v3 01/33] drm/ttm/pool: Allow backing off reclaim at the beneficial order Date: Fri, 10 Jul 2026 19:55:47 -0700 Message-Id: <20260711025619.2540575-2-matthew.brost@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260711025619.2540575-1-matthew.brost@intel.com> References: <20260711025619.2540575-1-matthew.brost@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Allocating at the pool's beneficial order normally uses __GFP_RETRY_MAYFAIL to push hard for a contiguous high-order page. When beneficial-order allocations have recently been failing, this retry just burns CPU cycles in reclaim/compaction before falling back to a smaller order anyway. Add a beneficial_reclaim_backoff flag to struct ttm_operation_ctx and plumb it through to ttm_pool_alloc_page(). When set, the beneficial order is treated like the orders we already consider not worth stalling for: __GFP_RECLAIM is cleared so the allocation skips reclaim/compaction entirely, and the __GFP_NORETRY clearing / __GFP_RETRY_MAYFAIL promotion is skipped. Together this makes the allocator back off quickly to a smaller order instead of stalling. This is a no-op until a caller opts in. Cc: Carlos Santa Cc: Ryan Neph Cc: Christian Koenig Cc: Huang Rui Cc: Matthew Auld Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: Thomas Hellström Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost --- v3: - Require a valid beneficial order before backing off reclaim in ttm_pool_alloc_page() (Sashiko) --- drivers/gpu/drm/ttm/ttm_pool.c | 12 ++++++++---- include/drm/ttm/ttm_bo.h | 7 +++++++ 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c index 3d5f2ae0a456..ab242ad4339e 100644 --- a/drivers/gpu/drm/ttm/ttm_pool.c +++ b/drivers/gpu/drm/ttm/ttm_pool.c @@ -145,7 +145,8 @@ static int ttm_pool_nid(struct ttm_pool *pool) /* Allocate pages of size 1 << order with the given gfp_flags */ static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags, - unsigned int order) + unsigned int order, + bool beneficial_reclaim_backoff) { const unsigned int beneficial_order = ttm_pool_beneficial_order(pool); unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS; @@ -165,10 +166,12 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags, * Do not add latency to the allocation path for allocations orders * device tolds us do not bring them additional performance gains. */ - if (order && beneficial_order && order != beneficial_order) + if (order && beneficial_order && + (beneficial_reclaim_backoff || order != beneficial_order)) gfp_flags &= ~__GFP_RECLAIM; - if (beneficial_order && order == beneficial_order) { + if (!beneficial_reclaim_backoff && + beneficial_order && order == beneficial_order) { gfp_flags &= ~__GFP_NORETRY; gfp_flags |= __GFP_RETRY_MAYFAIL; } @@ -814,7 +817,8 @@ static int __ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt, if (!p) { page_caching = ttm_cached; allow_pools = false; - p = ttm_pool_alloc_page(pool, gfp_flags, order); + p = ttm_pool_alloc_page(pool, gfp_flags, order, + ctx->beneficial_reclaim_backoff); } /* If that fails, lower the order if possible and retry. */ if (!p) { diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h index 8310bc3d55f9..fd814b5cf535 100644 --- a/include/drm/ttm/ttm_bo.h +++ b/include/drm/ttm/ttm_bo.h @@ -187,6 +187,13 @@ struct ttm_operation_ctx { * when multiple BOs share the same reservation object @resv. */ bool allow_res_evict; + /** + * @beneficial_reclaim_backoff: Back off from direct reclaim at the + * pool's beneficial order. Useful when beneficial-order allocation has + * recently been failing, to avoid burning CPU cycles in + * reclaim/compaction before falling back to a smaller order anyway. + */ + bool beneficial_reclaim_backoff; /** * @resv: Reservation object to be used together with * @allow_res_evict. -- 2.34.1