From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (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 E5D0C1E1DE9 for ; Thu, 11 Sep 2025 14:48:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757602114; cv=none; b=sO2pb+Z9aPnL2k9+U1IPgHg9c9VI4G0LJZlVQArMGFfY2eaSdfk2O1drliW1vga5slNPDYj6HaLjAdi+sUJc7VPyMUvq3Q2hWOVMDT25NQVbuTOi4VXhAkkiMG64WNzU9VkzP1zYCelNai4zgBQx1/kzfgMJS+em2rbY3wVT28Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757602114; c=relaxed/simple; bh=m/uaz3DoAhptjbjeLIaLsPknzmvO3BfMZnCy8E8H0uc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ssD2wVHiU8U8Tad2b3gP6q+bauL/Y6VVpxai/uA973qo81vyN66f9SFTwOM4zotHoZWP7cli5CYVSulY+49YXiWMVNzji+UBBO3B2t2dWZJnLYJ7q1XDAWhKmFFH2MPBieaNBu4xXe1nxto4FtWlD8BsS56AmXu3KfEU9dEoLvE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=HNenGeBU; arc=none smtp.client-ip=80.241.56.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="HNenGeBU" Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4cN0mR2sD2z9tVm; Thu, 11 Sep 2025 16:48:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1757602103; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rvKHZYTAposH6bvPHvR8LAHmRFjXDMsuj/JRvWzYtYc=; b=HNenGeBUV+8reHKwcktBZK6xQpU960cV6EU0gzsd9aALYNOOto3DS55AoTXFp+rb288pit Xp4xuBnQ6haTu7Acc0FE7W0RmfYnx6vsMnPCESSxI+452DX8k+Ux/z5EWP4XxEWQ6TAx4U /UcDQDlfMRwMlYvCMKun5BGr+pdXc8EYxCTHyi0nrNOtzDxrHAxNvp3MG1SBanxsJqIokS V3GqEY3smmpxIr2yPeUFPQACZIvY4CR5W+ww9QD/AqYecc4NaglcPsw2ysS2yChDmNj50x 4KzQxdhoYNYKyoMXnta9BNVKV9XPneByrO2XkJkZ5xxw7xFN+cN+P6xJmIgjnQ== Message-ID: <979f8223-68b0-4a75-b410-fd86cfe6c372@mailbox.org> Date: Thu, 11 Sep 2025 16:48:19 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] drm: ttm: do not direct reclaim when allocating high order pages To: =?UTF-8?Q?Christian_K=C3=B6nig?= , Thadeu Lima de Souza Cascardo Cc: Huang Rui , Matthew Auld , Matthew Brost , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kernel-dev@igalia.com, Sergey Senozhatsky References: <20250910-ttm_pool_no_direct_reclaim-v1-1-53b0fa7f80fa@igalia.com> <262a176a-4c80-40de-96e0-c97f50c20fe6@mailbox.org> <3227b440-5dbf-433d-8658-f37f9561554a@amd.com> From: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Language: en-CA In-Reply-To: <3227b440-5dbf-433d-8658-f37f9561554a@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-META: g8qgqzdim7qgfppq9qk4ijdh1518qo93 X-MBO-RS-ID: 12c791ed71481f193a9 On 11.09.25 16:31, Christian König wrote: > On 11.09.25 14:49, Michel Dänzer wrote: >>>>> What we are seeing here is on a low memory (4GiB) single node system with >>>>> an APU, that it will have lots of latencies trying to allocate memory by >>>>> doing direct reclaim trying to allocate order-10 pages, which will fail and >>>>> down it goes until it gets to order-4 or order-3. With this change, we >>>>> don't see those latencies anymore and memory pressure goes down as well. >>>> That reminds me of the scenario I described in the 00862edba135 ("drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages") commit log, where taking a filesystem backup could cause Firefox to freeze for on the order of a minute. >>>> >>>> Something like that can't just be ignored as "not a problem" for a potential 30% performance gain. >>> >>> Well using 2MiB is actually a must have for certain HW features and we have quite a lot of people pushing to always using them. >> >> Latency can't just be ignored though. Interactive apps intermittently freezing because this code desperately tries to reclaim huge pages while the system is under memory pressure isn't acceptable. > > Why should that not be acceptable? Sounds like you didn't read / understand the scenario in the 00862edba135 commit log: I was trying to use Firefox while restic was taking a filesystem backup, and it froze for up to a minute. After disabling direct reclaim, Firefox was perfectly usable without noticeable freezes in the same scenario. Show me the user who finds it acceptable to wait for a minute for interactive apps to respond, just in case some GPU operations might be 30% faster. > The purpose of the fallback is to allow displaying messages like "Your system is low on memory, please close some application!" instead of triggering the OOM killer directly. That's not the issue here. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast