From nobody Tue Mar 25 21:36:12 2025 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZMjsW64wjz5rqDw; Tue, 25 Mar 2025 21:36:15 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZMjsW5bK7z3pTb; Tue, 25 Mar 2025 21:36:15 +0000 (UTC) (envelope-from bz@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742938575; 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: in-reply-to:in-reply-to:references:references; bh=b1363uwdxTdnvnKgQGRQCR34CuQpI2/Z6q0gLwgsmNY=; b=VK9j2pOrgcQWdANtd8z7mnbaPHXAS+qwAj+tVjjaFHWtM0XVpMaOR5WNy1ltUudZPjetz7 RxB8SO/JQI43IbFfRxZ4Ton9bwEn61uGLspaiqFVNKnNzYf3I0Luk6cTsaSeqJjXsYwXkh F7unHf6x8845PEdJVO+M3phZ8V/e8SB1QQELQ4KYWShEs32+OfGKGD/Drk6Efj1T2KDn7l +qaocwggwa2G/pCy678Fi6A2giUjUN+XmhzhuKIdJ8gBWZp+PBovij9Z6Zhshnv0nafLe8 11XDXBQW64GwtheC5WWH0N707ZWSxhcujE1wXv+iYt2mwRDWDU+Mp0MwC1H2Ag== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742938575; a=rsa-sha256; cv=none; b=s+BFxtPdZdjrKUgVnzEBnIvLUzkl87TOqKOxUNKD0vNk9cnfjMQUBFxeeYS3MR798znNAC bEUGpx71CNRK0oQ1v1cDmKvvaJ6hiGsn5ReYEmd6DHE8q8V9XWHP7TlDKGax4nA/FtLuoQ KxtIAfbV9hKNP0LSc4XxBL0iUb52fBYcEXao4X0kO7ima6Z+0EKmuu0JpVI4KrSZOXbhjN tweY1lQUnW3WuYQIb0l67Nx861ekh06d2izXsBBSYR9ABKTJk/+1SdNRFztRobgmYNeuOD 5I940OFgdvhn4MFVhXI/nNV0r0cQExzRqksR/aWNNZW2O12Aa/1S07T91BP13w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742938575; 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: in-reply-to:in-reply-to:references:references; bh=b1363uwdxTdnvnKgQGRQCR34CuQpI2/Z6q0gLwgsmNY=; b=whLWkhPre+YIbzB4WqMN1zGI+5Sp4Xcln8E6RN4yH+qZvsZe/pBVABVWZiEcgE2IyKupmv 5TlNE2KqpkSmoJcNa3yKdAqoBxKdGIWa6SfGX5KEt3QHBOC748GjPCD1FookUFedqFG9Gw iNeK0A3d5qld5GoDiXrXKnX+4dw5j2m23pMkhdT8x7CG4sht0W/5YoUNc9AbXdL9/bojwY orXtc74muHg1qocOAEv9NXFViIxy//HPpc9nJNtpbz9tKnZp//q+wxKCaKMzzhoXFgVIxi zakTvugifGDAEhZRrbtNI96yjx0SD1ELfRe91ae75vvw3WZO7pr6sFzme05zyA== Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZMjsW36XTz18wh; Tue, 25 Mar 2025 21:36:15 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 1535AA64805; Tue, 25 Mar 2025 21:36:11 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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 mail.sbone.de (Postfix) with ESMTPS id 905882D029E0; Tue, 25 Mar 2025 21:36:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id 4OGKPGYRFfxP; Tue, 25 Mar 2025 21:36:12 +0000 (UTC) Received: from strong-rtwn0.sbone.de (strong-rtwn0.sbone.de [IPv6:fde9:577b:c1a9:4902:3e64:cfff:fe55:bc80]) (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 mail.sbone.de (Postfix) with ESMTPSA id 696D22D029D8; Tue, 25 Mar 2025 21:36:12 +0000 (UTC) Date: Tue, 25 Mar 2025 21:36:12 +0000 (UTC) From: "Bjoern A. Zeeb" To: Olivier Certner cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: Re: git: 718d1928f874 - main - LinuxKPI: make linux_alloc_pages() honor __GFP_NORETRY In-Reply-To: <3046625.S5UcXbOgvz@ravel> Message-ID: References: <202503250919.52P9JfOA032702@gitrepo.freebsd.org> <3046625.S5UcXbOgvz@ravel> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed On Tue, 25 Mar 2025, Olivier Certner wrote: Hi Olivier, >> What is the drm code in question? ttm_pool_alloc -> ttm_pool_alloc_page()? >> As all other uses of __GFP_NORETRY in 6.1 (ignoring drm_printf.c) seem to be >> in i915. > > Yes, this is indeed targeted at ttm_pool_alloc_page() which tries to allocate contiguous pages to fill up the pool (but not in 5.10). TTM pools are used by the amdgpu driver to build its translation tables. Great; I think with two other work in progress bits the disabled fallback in there could be used again very soon but that'll be a discussion for another time and place (and likely people). > Calls to functions other than (linux_)alloc_pages*() are unaffected by the change, and if you dig through all the references of __GFP_NORETRY/GFP_RETRY (including those from files under 'selftests/'), you'll see the built GFP flags are never used with (linux_)alloc_pages*(), except for the only reference you mentioned. > >> Are you sure? >> >> i915_gem_object_get_pages_internal() in drm-6.1 at least seems to >> conditionally pass it down: >> >> 17 #define QUIET (__GFP_NORETRY | __GFP_NOWARN) >> ... >> 74 page = alloc_pages(gfp | (order ? QUIET : MAYFAIL), >> >> Seems it can deal with allocation failures, lowering order or returning >> -ENOMEM from the function so should be fine hopefully. > > Yes, I was aware of this piece of code, but obviously it cannot cause any problem. > > All calls to Linux's alloc_pages*() can fail *whatever* the passed GFP flags except for GFP_NOFAIL (and that's the only exception). Ah I see; that's where the M_WAITOK logic in there comes from. I was wondering about it given others like GFP_KERNEL also being mapped to that. Sometimes that makes me wonder if we should indeed pass the gfp_t all the way down to the actual function doing the alloc and only there filter and convert rather than doing that earlier in wrapper functions. > Callers always have to cope, and specifically when specifying __GFP_NORETRY it would be foolish not too (and that wouldn't be allowed in Linus' tree anyway). > > If it wasn't for that, i915_gem_object_get_pages_internal() does the same lowering that ttm_pool_alloc_page() does anyway, as you noticed. > > My sentence was indeed too strong, as I was still swapping in context for this work which was done months ago now. I know how that feels. I just started looking at something I've done a year+ ago completely outside my domain. > I reviewed all callers not only for GFP_NORETRY but also for most others GFP flags (I have tweaked grep files for all of them and over multiple Linux versions), as I started some work to document what the Linux guarantees/behaviors really are and then some other work to rationalize how we translate them in FreeBSD (there seems to be several possible improvements here). Unfortunately, I have stalled that last work for weeks now, and probably will for a significant while. > > Given Linux's contract on __GFP_NORETRY, it is arguably not reasonable to spend time compacting memory on such calls, that's a deviation from what drivers are supposed to expect. > > Oh, and the rest of the commit message also doesn't mention that I also tested this change on machines using the i915 driver, without observing any problem or change in behavior. Fantastic! Thanks you so much for the follow-up. It clarifies a lot and makes sense and is very helpful! Lots of joy, Bjoern -- Bjoern A. Zeeb r15:7