From nobody Wed Mar 26 10:26:44 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 4ZN2yk3LQXz5rk4P; Wed, 26 Mar 2025 10:26: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 4ZN2yj6H65z458b; Wed, 26 Mar 2025 10:26:53 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742984813; 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=MIC/mJwDEnGAn9XD1/zTdyno6AEa7iYlcq1oCFxpHZY=; b=noKiC+VLZEOgO5QTuxqm9ONQ5C5GlhpZ+C2vV2wZ30P2z1GQK+hvxpe5H6nW0fqFjXwsU2 3xs+7DxHSE9tn5pJHMOGvifSA7EsD6lib3qew9LHgsmmJbs30vggQKPT26NoI08tDRLvk2 A6QwlR8/QC02oQVVqDVL2NWffy3lkG9SDQx0hB+E09Qs0RF+kGD32d32qp8nrkynApWadG ykYqAwWFCsZv4yoAFBMbgQwdOBA3wl+6uLwkMPIBv8olZdu1k84k4tmT8BRBTEcp7eMYSh 1OIAvJF+mjhKH3Os9PKRJioVCDO39hgWXfrGWNM0h3bCQh65D+5mjz4aVGKeHw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742984813; a=rsa-sha256; cv=none; b=D+6nUVkskNPJMKOzCVMNL0gVV3NOVhVp5cOod6xWVoKoE3CNk1GSLyG5fnpSB8tdtk5DZY lW7YljvFN9JpUfK8lDcG2mx4KqF2Hc6vPPateCQRF0leTSeCrtwhAba0qon/SaxePjKFeG Oqq4Nq+Kq1i4tSePplafSdeCEM77OrkMhvkF16f5oaKS4YVVwNSTn9bGZDo1OZl/6912P2 KoxPcal6bjymvw5UtbN/azugu/puB1mrcCS3A3qYKE+RH7Fz1PXcduNsCEHPYh3YZXm/1K VkcemRznVdB/VStLaaH169AwW6ZlUNRSCydfMpJE1KZccs6a4Boud72LSCa+Yg== 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=1742984813; 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=MIC/mJwDEnGAn9XD1/zTdyno6AEa7iYlcq1oCFxpHZY=; b=Bue4aHPolnak1C735JfWdd+eiNBuL7bMs98B3OHfIRzH2BoPr50TpXyt6T0Iy9K5BalIJS mVHCpvVKy/D8InoqFbVJiOHSci+MHgkBsa979sHGmSpxWYrU2i1CodhzEX9evHX3k4Zbi1 07RiC6d4GAWyaCYo7SUZGwwO8GSj4x+V8VvX4eM4zvYN0O7yshViX45bAHNB4DbRDSh2NQ VwDEOCXata1uWp7t70O3bkJpZi0UF8nSDlwbLXswXxWsVd6CXx49/LcG/ySJLgvytWHSws zk+bmadSxw3rcTsN249YUuVvoXY1LUGpJiWQixjLoWHoHm7ufR8EdcIuB8tnLg== 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 4ZN2yj0d8tz1Q1W; Wed, 26 Mar 2025 10:26:52 +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: Wed, 26 Mar 2025 11:26:44 +0100 Message-ID: <6026448.Zv9zXsTiuT@ravel> In-Reply-To: References: <202503250919.52P9JfOA032702@gitrepo.freebsd.org> <3046625.S5UcXbOgvz@ravel> 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="nextPart2760223.TYJnH3iKXO"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2760223.TYJnH3iKXO Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner To: "Bjoern A. Zeeb" Date: Wed, 26 Mar 2025 11:26:44 +0100 Message-ID: <6026448.Zv9zXsTiuT@ravel> In-Reply-To: MIME-Version: 1.0 > 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. I'm pretty sure this is the way to go, as it will allow us to choose a correct behavior in some complicated cases where multiple GFP flags are specified. Today, some of these flags are converted to M_NOWAIT or M_WAITOK early (and even at compile-time), and we lose the initial request nuances. GFP flags basically say how many retries and which memory-freeing mechanisms are allowed if the allocation cannot be fulfilled immediately (and sometimes, provide some more context about where the allocation is happening), which doesn't map to our flags directly (except for GFP_NOFAIL, for all other flags we need to use M_NOWAIT and then have various fallback paths). Although it hasn't happened yet in practice AFAIK, we could even end up with cases where we could both set M_WAITOK and M_NOWAIT (which is an error). An additional benefit of this approach is to remove the need to recompile LinuxKPI consumers when changing the memory allocation subsystem's behavior. For example, in this commit, __GFP_RETRY is now defined to be non-zero, but this doesn't affect previously compiled drm-kmod modules. In other words, to change the behavior, we currently have to change the interface, and although it is a small change, it introduces a bit of friction for testing. > I know how that feels. I just started looking at something I've done a > year+ ago completely outside my domain. :-) > It clarifies a lot and makes sense and is very helpful! Thanks. I think I saw your recent work of yours on LinuxKPI memory allocations, but merely glanced at it. If you need some support or to exchange ideas, in particular discussing how we should map GFP flags, feel free to contact me. Regards. -- Olivier Certner --nextPart2760223.TYJnH3iKXO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmfj1mQACgkQjKEwQJce JifCvg/7BhZlbaHsXqu9BMA1ktPYqK1ClcMuroSlM7Dbx8KxLP3ru1WBJBnBt19T j3FbH8zZZIBA6PuNz3ZI+pgN9pQ/7/L1Q8XLfLqUISI6X6MQArXRvht3nil8IC5a 4Wbp38FZtkqYScouevbF0eO/j8LBYIvtKB+RRzPfb/Nc+gA4vjS4D4NLaXb1nOld TbP+pzuSncimOVfqybvuz85EeBD+9YtyS5ZPZDrRAKWBJLBGZPUDJP2Y3DLU4jQ6 yrXxI4+BydP8LLSfx7ovS3AFecEpqq6ZrHqsimFnECazaSJP9yEuBzCLEv5cgdb4 cOxLZOjVghqvDWq+y6ldwz8WyMPVEFaVgzG3Ui6Z5VRx2fAi43VaJnxIZNS2zrKg RgBa8BCQ4DaYeCxUi9Z40bOg5gKb0TfFxuV8jGjjTt/5dfLI4A1EKG/T1k1Cp5Nm XLb4I3115/GCb647pLKC2PE1qsKGNs3XYAWBhfuHvte24NrnCZZyTmzGku5uWPaP 8Wq4WzUJSQLAauZnD29H9JqQHYdam1Nrwi43eoPmp6fYu+aWa38YFTkrkCxZ5Zhd rPCILJ7W0mPmyHyPVcd7kTXOyzNewE7HjWfzRKMoUQ9NHAO4/vnmjngsWig/Pv/Q JO0gQHvZkVqWl/dIUeBzBb4UaytE9vd2E4h86+pKzWt3xm+RK5Y= =al6f -----END PGP SIGNATURE----- --nextPart2760223.TYJnH3iKXO--