From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 993771D5174 for ; Mon, 19 Jan 2026 09:33:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768815225; cv=none; b=LspT0kUNANkfMYh8vFYmQIrm1jVThjnnXEH433W7KxYWF6nLg2tky2oQTSFJCq982NiE60OTiHiGWnNZ2DvFYc17BEAyGxiFrYaAuJtJaBbIdLoe6gZHF4yh7qu8lxow3WUT2c8mPddhJqGy4bAXpeR3rjeQTfc4x80XnNkVIxM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768815225; c=relaxed/simple; bh=Qfq+YGyJejMJFEyBEHzlzdNJQfj1V+dSrryNwTI+upA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=gjd39TJ05aW0EdAgvJYMiXc+pUWOLARo1YDMLOHNjJMQshwgk5BCvZzisezsNtD/1UChbJLQnKYT/e+7gdcR73zCS+WVYuZ3jePSiZq8VfbyYYjgvmaatOX9Qp6WctMmm7f6z0TttOtF4Ok7tUm2TiJSPUJfh8lihaOGAnG16io= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WUQIJxJa; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WUQIJxJa" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-47edd6111b4so35673495e9.1 for ; Mon, 19 Jan 2026 01:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768815222; x=1769420022; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=vxFUMINiROnPGneWmNkTLgSLfIoIsEZfiy7Cs/FTrhE=; b=WUQIJxJamOOepf+j+NyCMHAatXMTR58D/UAXrQfiR71AqCtJybBlx5YVNzeTuCAYiL 7c+T1ZBJyO+NYGxeuRcowrZ+2VOyXw8JWHYeC9WBuKAV+FGI4M0XNQnWje4mVRHPSf0Q UMoNnyvIQPMdZ6iEQ3/WAaD1FY60I02MH3XzXXPXWQuweh22TEXfZXpSbnL0cdhv3Mxp 1kQIDHf+p9U7qqF3FbK8TARu8Zvi0C0fvEJ9UXBPYNgpvCRfpdFVWpvH2BEXqTk0dIgJ kb1I8vvzKuNALs6eM20qsRq9P5RIsruWm4YWlA/HHbo6cfq/RixY9goJocjJ9Fr5YU6N x+lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768815222; x=1769420022; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=vxFUMINiROnPGneWmNkTLgSLfIoIsEZfiy7Cs/FTrhE=; b=f1wCC2KaBipdAF1mo1TKTJ+3cDmxEbPFuHf0kjkL6jeMnonH9+71Pmcp8KBGGet726 RHNjFnsZz+xNiOAaXWeOqxcExq3MPXj0ZE8kAnawk68TmTPwDQfkCT3y8d5ve5fi36LU 93DElx54hpVtB/xCj8mrOEky6HXHE/duV+Ybb39Zzx2oLBFR5FkepvBKoC823uUpq1X3 7UZl81AhVI3dhTDpQ7BXlnmTIO5Dc/ngmtVZf7ddPkcDZzSuGByo07Nk5uM5ErBdJsmO KonfabZxqTmT2KaNIbuEtzTkPRdKfG3OMHwNU2T8SGS37Pb9S9MWZvmDpdCmrMThpMbo cTkg== X-Forwarded-Encrypted: i=1; AJvYcCXBC96CjHc/XIyeBg27iB+NC3/vJDjejj/UdB0SiUxUedZOaMCcal+z1VFFl89Pzj2k6tT8tzUGE8OfbZs=@vger.kernel.org X-Gm-Message-State: AOJu0Yz0o/eQktXnWpre4x5wrugzi9Bo86Mvkphz36oq9gPazyo/CYow UCJmhCxWFP2SkZtL6RwpbmjOh6c6/z/t96ij72h6EBiUKN+GevhztAiS X-Gm-Gg: AY/fxX7Ign9A+NTeTUX7/DbpHkAZ1DCdb4ywYp9Nf9JQEIYdNkoiAXhUW60pRi6Elmf JYBWryoBL/AP0VKoe3fLAOuT94UTFw14+lvU0vcKm5aGYhY8s9Tqza9KITqsDr6WOAmRwADpiE5 s4jmYBbPIZRoRh6s7ycEW5cGNQSXc1GPQwiMD4XjH0//E+aWRWukGqMUzXvdeeGifHe2ZK3eF/m DaMRxErzSouKep/nbY6UJ3BHqvtuOlkiUcGgOyT3mTeckV+kM7Jg0XxtVv0d/Q4LwdgcX1rhW5B Qx6tLhSUd0HQA622JAdGbW1JcxxGosWQcA7GaoOPGv5+wQCWrmBz0uJy/3WV0AWMAlTwpuGxQyN nQtwL0IdrffKWdMTo3GejgtpMyJvYYs9NJu4KgoF4XZ5YpYFSaDu85Y9HMHNODGELZUDaq5Y+c/ 9OPGXTBpwH4HnkELaMQfYZ6uQM9zLoGd05G56xkJ4oB45wV2R5jjYG X-Received: by 2002:a05:600c:5291:b0:477:b0b9:3129 with SMTP id 5b1f17b1804b1-4801e2eef8bmr108328255e9.3.1768815221752; Mon, 19 Jan 2026 01:33:41 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4289b83csm239739415e9.3.2026.01.19.01.33.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 01:33:41 -0800 (PST) Date: Mon, 19 Jan 2026 09:33:39 +0000 From: David Laight To: Andrew Morton Cc: Eric Dumazet , linux-kernel , netdev@vger.kernel.org, Jakub Kicinski , Eric Dumazet , Paolo Abeni , Nicolas Pitre Subject: Re: [PATCH] compiler_types: Introduce inline_for_performance Message-ID: <20260119093339.024f8d57@pumpkin> In-Reply-To: <20260118160125.82f645575f8327651be95070@linux-foundation.org> References: <20260118152448.2560414-1-edumazet@google.com> <20260118114724.cb7b7081109e88d4fa3c5836@linux-foundation.org> <20260118225802.5e658c2a@pumpkin> <20260118160125.82f645575f8327651be95070@linux-foundation.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 18 Jan 2026 16:01:25 -0800 Andrew Morton wrote: > On Sun, 18 Jan 2026 22:58:02 +0000 David Laight wrote: > > > > mm/ alone has 74 __always_inlines, none are documented, I don't know > > > why they're present, many are probably wrong. > > > > > > Shit, uninlining only __get_user_pages_locked does this: > > > > > > text data bss dec hex filename > > > 115703 14018 64 129785 1faf9 mm/gup.o > > > 103866 13058 64 116988 1c8fc mm/gup.o-after > > > > The next questions are does anything actually run faster (either way), > > and should anything at all be marked 'inline' rather than 'always_inline'. > > > > After all, if you call a function twice (not in a loop) you may > > want a real function in order to avoid I-cache misses. > > yup I had two adjacent strlen() calls in a bit of code, the first was an array (in a structure) and gcc inlined the 'word at a time' code, the second was a pointer and it called the library function. That had to be sub-optimal... > > But I'm sure there is a lot of code that is 'inline_for_bloat' :-) > > ooh, can we please have that? Or 'inline_to_speed_up_benchmark' and the associated 'unroll this loop because that must make it faster'. > I do think that every always_inline should be justified and commented, > but I haven't been energetic about asking for that. Apart from the 4-line functions where it is clearly obvious. Especially since the compiler can still decide to not-inline them if they are only 'inline'. > A fun little project would be go through each one, figure out whether > were good reasons and if not, just remove them and see if anyone > explains why that was incorrect. It's not just always_inline, a lot of the inline are dubious. Probably why the networking code doesn't like it. Maybe persuade Linus to do some of that. He can use his 'god' bit to just change them. David