From nobody Tue Mar 25 18:41:46 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 4ZMf0L1v3jz5rdXD; Tue, 25 Mar 2025 18:41:54 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4ZMf0K729nz3pJ0; Tue, 25 Mar 2025 18:41:53 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742928114; 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=UKfM1ymbnWcwdFIaWSs0x/atwbhspviEt9CfofhmrGQ=; b=TitPhmIPnfFrxJSlZm4yql0JYwt8hezpvONSzgCgwzVpW0jWzchSA6+a/JIa1j7MHxqjRn JB02xtxE7SvNpS1baFJMXCm9DuZ4kVJ74oXJjMuqCDHnePf/e5ZIvT9pZe2PZZqzAks0K9 7WFo+/C7tLheRCNdKAyyif0rPega5wmS7XL8zsKcGlXNXw6ByvK3g+p5ukGG3a2fm60jn+ aty3US++lH/j1yCQiD/3qP8omdnbqG3wJLIRe/gnUyIxp0Jx/x+aycaI3KM7KBcOxwx43X 2hrQdqLp3gMaKXNNh7GbZC6Zl0lCG8NGjB31MfqRQFgTpV0j2UDknfAT6BxNmQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742928114; a=rsa-sha256; cv=none; b=XzxFavOmJVikov4mlwDUpVWCjeSmU2g3/w7g+5R4ZDmt40vE8a2QRlHPkz7z8TfOs+d/9l 99YOvFLUB6tWdTSN76xNbR3mR+LJvF5WlhRKBkKzgyFiR3pXbw4qd17EIeSqze53z1mSXZ SvRsHoQGRs/R0/cgW+wi8tYVcp3xSk04Y37uim3ek0/2iT0Vw+JLX6a25dahX6M56bWjOY cvlqob7Fj+eQ/bNZGCE7girDHQ45bWbPiUcEmvZL4hMHMMhSFS0MpKvgJe/qyPcHh2TNtP 8ndv7LPwAtU5SxJe7ztov1KLIqG4Vp2JqgeKkHLniRu8Yl1KZFUKfH8jNvzbSA== 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=1742928114; 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=UKfM1ymbnWcwdFIaWSs0x/atwbhspviEt9CfofhmrGQ=; b=i3lhQv74PNpR4KHfvLqZe3FFNQ1Scl1K9tGxPRzXGTaoR1XYIkG+RorJ8ljlpFyR66j1/d GN9fMZgQd6AEXdwqasqdGAMeDmN8NMaPUCLujJzTvTIbhvTNg5ugamsVBTiXgYQKbUHPtv xdJFrwQJJThINrVZQZTh0il1AqFDc9kif1OwSm/QS1bM44+cw/22wXMkWAVcvBVmcgW7w5 pNvCBpHVjrXdVtPatxTi01sBHKz+5PyPm6vZtaTZIsyevANibAiyezZYTt4w6X/3yk+Y2z 3CSy+2gTdvoZhbossnsixWeRGUcRAt50ILKCIEydp1YBBoAT4dO8v8N/PsCyYg== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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 did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZMf0K2qlsz15YJ; Tue, 25 Mar 2025 18:41:53 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: "Bjoern A. Zeeb" Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 718d1928f874 - main - LinuxKPI: make linux_alloc_pages() honor __GFP_NORETRY Date: Tue, 25 Mar 2025 19:41:46 +0100 Message-ID: <3046625.S5UcXbOgvz@ravel> In-Reply-To: References: <202503250919.52P9JfOA032702@gitrepo.freebsd.org> 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: multipart/signed; boundary="nextPart2203838.BuRyMYtAyW"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2203838.BuRyMYtAyW Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: "Bjoern A. Zeeb" Date: Tue, 25 Mar 2025 19:41:46 +0100 Message-ID: <3046625.S5UcXbOgvz@ravel> In-Reply-To: MIME-Version: 1.0 Hi Bjoern, > 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. 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). 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 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. Thanks and regards. -- Olivier Certner --nextPart2203838.BuRyMYtAyW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmfi+OoACgkQjKEwQJce JiepbA//bxDMv9nQwrb6Cp9RLDVGwKAHSyZJyT3Pz2sYbpr4VUXFPvBe4La4uLpZ 23ZJ80M4HnukGuSwkpGauifFHGrfu9I5t727qIpdoP/elGa6mw1qzCDQ6YpJ0str f5NMTRrgFoPHjOHQ1tZgjlE8Q4LA8LWzc3dvvuW8aklPYlU7g70MZsFbCIZh9/0W R8EbcowHh0lJNU4U9sl6vH8OZqGdCJojNZxHEt89+W/yaDskPQqppoTTbibvX9Qg GhhksWeNKVJK8gYD3R89313Cjl9FvW5ANPCKUiAK00iVZhBGAt77GLuZ6koiY1e8 Xqamhf7jNmzdYSJv6VVB2osILfijX2nC8No1FqMm3uB+hKMB+jaFfMTrvxeRLOwv zvlH3xPNnLUIjncZZ5atX9wvv66oOr7zSQ6DLCbUBqVEPqVAYjMUWd/9vewSHFuO LozI9AOxJNEQTEiOCPyrWJs4z1xU263t0XFPZSlAXqnVM2Y8NKqE90mRPW0UjgoJ vZH/PEzEZlochyml2W6VNXZdwEkLq9Fs2eadJ5pwX/Wzqsa4SdNEv/DYFjX8VxzB nGXVpCWMLBs2z3I3vFM/BLkjAWjy9dAn8AUgborrifLaNUtlmuy4SyQabAfg2R2a /7GcBvsjFv5/84j8GcQCND3CNTKx1lMGW044p+GgCA8RcZUtV2c= =l+HE -----END PGP SIGNATURE----- --nextPart2203838.BuRyMYtAyW--