From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CDD4C54E5D for ; Tue, 12 Mar 2024 18:11:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0412D8D0017; Tue, 12 Mar 2024 14:11:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F0A208E0007; Tue, 12 Mar 2024 14:11:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D83DA8D0068; Tue, 12 Mar 2024 14:11:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CC0278D0017 for ; Tue, 12 Mar 2024 14:11:31 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 84E9E1C097A for ; Tue, 12 Mar 2024 18:11:31 +0000 (UTC) X-FDA: 81889179582.11.122A41B Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) by imf06.hostedemail.com (Postfix) with ESMTP id 72F0A18000B for ; Tue, 12 Mar 2024 18:11:29 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=ionos.com header.s=google header.b=TLfZ4aft; spf=pass (imf06.hostedemail.com: domain of max.kellermann@ionos.com designates 209.85.208.174 as permitted sender) smtp.mailfrom=max.kellermann@ionos.com; dmarc=pass (policy=quarantine) header.from=ionos.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710267089; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ClDlP3smAv1X4jMWrBHkgaTmWKeGG4uG9hpj1wGBbXo=; b=S2tzQkaV+ODM5bc3nc2H5A821Nd5mfNixCMJ7aguJ3fNVv+XHJyQMJkR53aSu0kXqZbUys FfZg0spwOEtqUORSiKl36vfbuVOhz/S0Ddoot7fEdKHK7wFAB3O/9PMOvsRIDSV9EnHHMV AdidrZyRjlTZ71Q3cV/sc6HNu1n04tk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710267089; a=rsa-sha256; cv=none; b=SP6GmC2ay0LfTzZ34RxyFS3sgf1e4SsMiUip91FB6tI4w0dYlcvI/6zqyITBjMl0YyFSb+ saxrnOequJggkAC3evhJGSkT8kvxsSG1aCcP1+N5Z9o0x/epMB6wfajT3l6i/obo/M7Yoj iVnrq8p1BgZ3bfC61/+0uqCmq4g8cZQ= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=ionos.com header.s=google header.b=TLfZ4aft; spf=pass (imf06.hostedemail.com: domain of max.kellermann@ionos.com designates 209.85.208.174 as permitted sender) smtp.mailfrom=max.kellermann@ionos.com; dmarc=pass (policy=quarantine) header.from=ionos.com Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-2d3fb16f1a9so1328381fa.0 for ; Tue, 12 Mar 2024 11:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionos.com; s=google; t=1710267087; x=1710871887; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ClDlP3smAv1X4jMWrBHkgaTmWKeGG4uG9hpj1wGBbXo=; b=TLfZ4aftRwP2zdZu/BsRzlPFO+FyBSvgMC4zh/Yxoy9UGcS4AzeXEQKV98OeHq2sfh FzIpJlT+EB6TYXZIUJeAE6+TsRMRGPcc58se9/QjjYr3RW3/IMB63Jx6nTZMiGVbMaVs fynPo8DEwd/YocprZG6LMXyPhsK+oyeQi0eB/YZhECq/UOLY9Rs/qOv7LV+hBJnWh2ni Uhxko9vgdd0bmCOBGabcMCxMzV8D1SyYiN/nWnP3pU6KOwuNTEcxHfb84l+SpSjNYMCu WlfP1IsoJD22DOaCXKUjHo2x3j8OSQmcHNY6PCIrHwa4c9yPH6lHo3HNHszsVDe4UH3j ypqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710267087; x=1710871887; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ClDlP3smAv1X4jMWrBHkgaTmWKeGG4uG9hpj1wGBbXo=; b=e3kotCpJWUVm/txQk/Ppaa8HH0PNHFt/PvSZDUsLdEZVn6JQNXhHcPlPqHc2RnYzjv 0GK5D2QhWRrXRRLCB4IjTkMVmFO8hKl3IgAcF2F44qYHU/eaNXNG5Qhuzzd3AuSvZ/6l uSlQnMbywFFpGO6p8+wUb6wV40CmDyUo0Pe2SqkeQg/G7WeI5AZLcjHClVfTxqNNU3lA +OTsD01J1+Q1vG3qOwUT+tg1Jswb1pbQ1T6my4trlrD0I37L+KCl8wC7VMmb0F093mmc xL/sWRtb+fPNLtWAiFpYBj8/Rv7HJ1AK0cf0ZFzqWhX8/MlqMmLgRqQtIaMUuHBXS7At YaKg== X-Forwarded-Encrypted: i=1; AJvYcCXXrJ/rllFydezeXV2D/4L6hNxBnJE8FyArUirgarhbGdn8YkD7OXBn2wHee0hC60l/239eKa279D461ExjsnXviRI= X-Gm-Message-State: AOJu0YzLHiTRt49GXDAQSFb6f6zuvJ1UgWDgxhDHUUFxD108y6eFCGC+ STAvlcJDB2J2m0K9PGjNAyIAEOXGP9dtZ4ZZsmC4EolPvg+yzBBjgqEFqeTUpPlG0igV8Nq/wb2 4K/zjeDpi6FlJDPnc9NPu9TPrXJ/YuI+lc++PEg== X-Google-Smtp-Source: AGHT+IG5phwWtKzG7Qn8SCd38fKlm0T82meI6dpteEwueBcej3WDzgs7PvhaHkNK5lcZJgN4BCTdYivMSrjkWh/EdOQ= X-Received: by 2002:a05:651c:324:b0:2d2:31a8:cb1a with SMTP id b4-20020a05651c032400b002d231a8cb1amr113200ljp.13.1710267087555; Tue, 12 Mar 2024 11:11:27 -0700 (PDT) MIME-Version: 1.0 References: <20240312094133.2084996-1-max.kellermann@ionos.com> <58fbe42a-3051-46bf-a3f9-d59da28a9cd7@redhat.com> <37ed1ddd-f1d0-4582-b6c5-2f4091dc8335@redhat.com> In-Reply-To: <37ed1ddd-f1d0-4582-b6c5-2f4091dc8335@redhat.com> From: Max Kellermann Date: Tue, 12 Mar 2024 19:11:16 +0100 Message-ID: Subject: Re: [PATCH v4 00/15] Fast kernel headers: split linux/mm.h To: David Hildenbrand Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, willy@infradead.org, sfr@canb.auug.org.au Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9fdtwehiwkox951ag7sun4azzh7q33dd X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 72F0A18000B X-Rspam-User: X-HE-Tag: 1710267089-368939 X-HE-Meta: U2FsdGVkX1/e6aWMgaqAhmyU442253qk+LYDeLvNL33UGgDcFkWJrhFsemCCqPH6kLGX/Xnwjgh22PH+2bN3na3tz9tAzHOBtF81be9IwyIURmWRlFoExHwp/dWb9ltKIhQTd5vplC4TpAJgt/gbEwAyUIVYSvJ1cQagQrG5QKdXO4Cv3VH+hgh40LyYwKxst3NT3xAO8Z4XC7RAMoS2IhoRUFZpDwB4ZyIuj/Zb0PkD8+oaFn/xJYv+zG39E34vQwDnX/i2yrVXNKz2xnATDScuZkLRtTt1WobdB36Ajn4y1CPyT6rUyEQxl1Ru8CZpRKy8URKK+ljoNtcwqPg5aQ1dzbCNbdSKNN/6+g3Mo7nvX9lqdLJjcQMM1a0D90/HUYJtHnEypKEfpJbDq6VphAzrUtADPuxc5E7rCDq10llO/uBjIlbaPMommNzxI9JOALGqZ8aB+9XQMqrpyCwnoFE8tQma82RRpIb7nWB+OYrl3Pt1kLBDTn2CzGcbIY7UPah4HvPB8D7A4NnpVdpWbvYYhw13/GymK+fC+n2VfYGLO1I2uVnwMXIkIHTMJ49c0RD8h24tPSSZuoK/GBYDvzg0ogYwKqtqtmyJOKsenHIHslIhU/68LGt3ZKPB6e5qH4wl6zefmtO/H4iR3rU/xgRu/KubHZ0ltZCQ0APvsrjd7Xfbw4FUCYecFEFWPo3MmMvRg7SuEHmD2V1b1gbi/b0gcjp6qClmVV/T8Jr5z5OrU9lKev4BLXiCSR8m0B9+iyQWLRWFLJRX1PA4Z9oEIJ70I0nwUnMkhf3Y52+Ap4jMytrif7kRyLGMl+lZ0biUylKvmXyAtGMrp5bU7uKKm+UdOSyFTZjmS9AysXXY8zcQBzVQ0RuPuZbcO0FkzyERTYnFpmkYxlDMGI1ENsyLjy52todxe82mE68yIgGM7D3yKC9xWudss6DtWiM/2igq3nFZTOjDry+bVaGZ5Bi Sd09P5Ib qxlDVW+BPjIbpfPNdN61AXWGAxweLknuqcqsoMYB7BEFpbbMT9YfA/hML+KNpEkg1KG/Nr9CsWHvGn6CHXQMZqEXYBwqkwtbukq2LrZ/BtPU/IAwskb+lMGOYRK9a2XaUKqENXzOhuOccW+uJbLpkuoiuD3Tku5AQZnVoB1mAAFyP9Coe4rJGXAGsnJiVshLvSVkKbeOAqqhgq/4cNouXlayaO0IcxoDvw6NYSVbHJKiNXpW3Xkj62IxgCyYi+Qtet25f3DWvtPmvc6on9Z7SfXId4wWi6iTEchlBMnohoJXtdSjXsgAVHmFSKYemjSbKek+J6cpSm07P8wsK/W+BrR96esIbSdHu14q5e1FPUWDD+RM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 12, 2024 at 5:33=E2=80=AFPM David Hildenbrand wrote: > Just curious: why? Usually build time, do you have some numbers? (This has been discussed so often and I thought having smaller header dependencies was already established as general consensus among kernel devs, and everybody agreed that mm.h and kernel.h are a big mess that needs cleanup.) Why: Correctness, less namespace pollution, and the least important aspect is reduced build times. However, the gains by this patch set are very small; each optimization gains very little. Some time ago, I posted a much larger patch set with a few numbers: https://lore.kernel.org/lkml/20240131145008.1345531-1-max.kellermann@ionos.= com/ - the speedup was measurable, but not amazing, because even after that patch set, everybody still includes everything, and much more cleanup is needed to make a bigger difference. Once the big knots like kernel.h and mm.h are broken up, we will have better results. And as I said: build times are nice, but the lesser advantage. Anyway, this first patch set was so extremely large that nobody was able to review it. So this patch contains just the parts that deal with mm.h; later, when this patch set is merged, I can continue with other headers. (I already have a branch that splits kernel.h and I'll submit it eventually, after the mm.h cleanup.) > I'm not against splitting out stuff. But one function per header is a > bit excessive IMHO. One function per header is certainly not my goal and I agree it's excessive; but folio_next() in its own header made sense, just in this special case, because it allowed removing the mm.h dependency from bio.h. Removing this dependency was the goal, and folio_next.h was the solution for this particular problem. > Ideally, we'd have some MM guideline that we'll be > able to follow in the future. So we don't need "personal taste". Agree. But lacking such a guideline, all I can do is make suggestions and submit patches for review, trying to follow what seemed to be consensus in previous cleanups and what had previously been merged. > For example, if I were to write a folio_prev(), should I put it in > include/linux/mm/folio_prev.h ? Likely we'd put it into folio_next.h, > but then the name doesn't make any sense. True. But since no folio_prev() function exists, the only name that made sense for this header was folio_next.h. If folio_prev() gets added, I'd say put it in that header, but rename it to, let's say, "folio_iterator.h". But right now, with just this one function (and nothing else like it that could be added here), I decided to suggest naming it "folio_next.h". If you think "folio_iterator.h" or something else is better, I'll rename and resubmit; names don't matter so much to me; the general idea of cleaning up the headers is what's important. > The point I am trying to make: if there was a single folio_ops.h, it > would be clearer where it would go. Maybe, but IMO this wouldn't be a good place to add folio_next(), because folio_next() doesn't "operate" on a folio, but on a folio pointer (or "iterator"). Again, names don't matter to me - ideas/concepts matter. I'm only explaining why I decided to submit my patches that way, but I'll change them any way you people want. Max