From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 8D7CA231830 for ; Sat, 13 Jun 2026 05:21:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781328091; cv=none; b=pC+5o+qTF1FVaWy9dg5MlYYfcT103elnM8t0nB62Zzq1nYuorY1nm/NTm9wFL5PlY5077k8mq/N9HrtjNGJlyIDNmqi+WeYXQpPqJVkBpFkvVydlJTtr3Rq6n4y1E6+eQpMd79o3J7BJE93uYkfJ3uPNw9fjSCxGhc769ohzBk4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781328091; c=relaxed/simple; bh=q4WbJ6VLc5DA2ziP7fewHhFGuusonCAwE8f3hiZ6CP4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=STemxlQqQnMe0N72sUZIyZfv+9F1OGRq0+kD1f7SPABPHAtT0Ai/joWxtUcYpwfCgfZnzPv4h1AZ/hEld3IB4hu9lxl9oyFQa0smeqYhIm0WM1t/20uRb6N/KJNsVrDy48V7KFQXBNYs1uvrFGfovORXh2IzESnQnT6NdrTtcCs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TqKsaocu; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TqKsaocu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2D8A1F000E9; Sat, 13 Jun 2026 05:21:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781328087; bh=cY4ulGls6JQt0yIjszAxVaniFh8xLiVdkDhW4rzHbcc=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=TqKsaocuMRNQYkmCNGvKzOjFOtNvuv/CVRH/AL+oEWHghWYzumjG9V43KL88eNKMo WAOinHgXNmAKqt04ooIb6YHkoLNBgkp0raPj7TcReGgJpX9OFUBFrI8VOBAz2/JDsi JMdZuRNvUx+wSzIxAfcrfrBMLU3QktZ4nb2Re6EnBRXCNC861h7k33xx+vW17YB6hH qSgD8OwzmV6ZQc0CZwXQAafd5/Ds4SyvfMjTr27nn/R6KelRtoDJl8uXoGKrRyOMKG O4DVTSOY6fFrx4rGmapcrO8iqyPwcEjRn64XMqsl4Pk869GvymUvDKWEFJRuHFdUww ZR2qJJWxuClEA== Message-ID: <951f3634-d9e6-44a5-85fe-666f6fdc8b72@kernel.org> Date: Sat, 13 Jun 2026 14:21:20 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/page_alloc: drop flag-conversion "optimisation" To: Brendan Jackman , Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan Cc: Gregory Price , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260612-gfp-pessimisation-v1-1-936eb04202e7@google.com> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260612-gfp-pessimisation-v1-1-936eb04202e7@google.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------hF9aylLo0tJ0Ntt9jCFGxhn0" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------hF9aylLo0tJ0Ntt9jCFGxhn0 Content-Type: multipart/mixed; boundary="------------pTYgLfOEc0GbcLNspxQa7E99"; protected-headers="v1" From: Harry Yoo To: Brendan Jackman , Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan Cc: Gregory Price , linux-mm@kvack.org, linux-kernel@vger.kernel.org Message-ID: <951f3634-d9e6-44a5-85fe-666f6fdc8b72@kernel.org> Subject: Re: [PATCH] mm/page_alloc: drop flag-conversion "optimisation" References: <20260612-gfp-pessimisation-v1-1-936eb04202e7@google.com> In-Reply-To: <20260612-gfp-pessimisation-v1-1-936eb04202e7@google.com> --------------pTYgLfOEc0GbcLNspxQa7E99 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/12/26 11:15 PM, Brendan Jackman wrote: > This code uses flag equivalences to try to optimise conversion from > GFP_ to ALLOC_ but there's no clear reason to believe it makes things > faster. Even if it gets rid of conditional branches, it just trades the= m > for a data dependency. >=20 > CPUs are pretty good at conditional branches. But, in my GCC x86 build > it doesn't look like there are any branches anyway, the compiler found > some conditional instruction tricks. (Caveat: This was extracted & > annotated by Gemini AI, I did not actually read the disasm myself) >=20 > Old code: >=20 > ae50: 8b 04 24 mov (%rsp),%eax = # Load gfp_mask > ... > ae5d: 41 89 c4 mov %eax,%r12d > ae64: 41 81 e4 20 08 00 00 and $0x820,%r12d = # Mask both flags at once > ... > ae6f: 44 89 e1 mov %r12d,%ecx > ae77: 83 c9 40 or $0x40,%ecx = # OR with ALLOC_CPUSET (0x40) > ae7a: 89 4c 24 60 mov %ecx,0x60(%rsp) = # Store to alloc_flags >=20 > New code: >=20 > For __GFP_HIGH ( 0x20 ): > It uses the Carry Flag (via sbb ) to conditionally add 0x20 to the= base 0x40 ( ALLOC_CPUSET ) flag: >=20 > ae63: 83 e0 20 and $0x20,%eax = # Test __GFP_HIGH > ... > ae6a: 83 f8 01 cmp $0x1,%eax = # Set carry flag if 0 > ae6f: 45 19 e4 sbb %r12d,%r12d = # %r12d =3D (gfp & 0x20) ? 0 : -1 > ae80: 41 83 e4 e0 and $0xffffffe0,%r12d = # %r12d =3D (gfp & 0x20) ? 0 : -32 > ae87: 41 83 c4 60 add $0x60,%r12d = # %r12d =3D (gfp & 0x20) ? 0x60 : 0x40 >=20 > For __GFP_KSWAPD_RECLAIM ( 0x800 ): > It uses a conditional move ( cmov ) later in the function to set the = ALLOC_KSWAPD ( 0x800 ) bit: >=20 > ae72: 25 00 08 00 00 and $0x800,%eax = # Test __GFP_KSWAPD_RECLAIM > ae77: 89 44 24 30 mov %eax,0x30(%rsp) = # Store result > ... > af2c: 80 cf 08 or $0x8,%bh = # Set ALLOC_KSWAPD (0x800) in temp reg > af2f: 45 85 c9 test %r9d,%r9d = # Check if __GFP_KSWAPD_RECLAIM was set > af32: 0f 44 d8 cmove %eax,%ebx = # If not, revert to flags without it >=20 > Testing with a modified version[0] of lib/free_pages_test.c (adding > printks with timing)... >=20 > [0] https://github.com/bjackman/aethelred/blob/2ccdc84ef087c2a631914f58= e106e99e19bd3b98/page-alloc-test/page-alloc-test.c >=20 > Old results from a Sapphire Rapids consumer CPU: >=20 > [ 67.157118] page_alloc_test: Testing with GFP_KERNEL > [ 67.157122] page_alloc_test: Starting 1,000,000 allocations... > [ 70.704446] page_alloc_test: Completed. Time: 3543002 us (Avg: 3543.= 00 ns per alloc+free loop) > [ 70.704456] page_alloc_test: Testing with GFP_KERNEL | __GFP_COMP > [ 70.704460] page_alloc_test: Starting 1,000,000 allocations... > [ 70.944672] page_alloc_test: Completed. Time: 239980 us (Avg: 239.98= ns per alloc+free loop) > [ 70.944675] page_alloc_test: Test completed >=20 > New results: >=20 > [ 70.079015] page_alloc_test: Testing with GFP_KERNEL > [ 70.079020] page_alloc_test: Starting 1,000,000 allocations... > [ 73.669396] page_alloc_test: Completed. Time: 3586954 us (Avg: 3586.= 95 ns per alloc+free loop) > [ 73.669402] page_alloc_test: Testing with GFP_KERNEL | __GFP_COMP > [ 73.669405] page_alloc_test: Starting 1,000,000 allocations... > [ 73.905084] page_alloc_test: Completed. Time: 235496 us (Avg: 235.49= ns per alloc+free loop) > [ 73.905086] page_alloc_test: Test completed >=20 > Seems like a wash. >=20 > So, drop the flag value coupling here and let the compiler and CPU do > their job. Superscalar CPUs are pretty neat after all. >=20 > (Used AI for the disasm but the rest is all manual). >=20 > Signed-off-by: Brendan Jackman > --- With the alloc_flags_nofragment() adjustment, Acked-by: Harry Yoo (Oracle) --=20 Cheers, Harry / Hyeonggon --------------pTYgLfOEc0GbcLNspxQa7E99-- --------------hF9aylLo0tJ0Ntt9jCFGxhn0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCaizo0AAKCRCGXBN6rc5S 1kMkAP9bzvsGcbgKObEHIB7zwKaD9KDRDhVqacr4Y57Bgs8rpQEAg98esywp6jDi pGg064E5KuAIpaUirNOoxQkip2fxCQI= =R0yJ -----END PGP SIGNATURE----- --------------hF9aylLo0tJ0Ntt9jCFGxhn0--