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 0AE5EC3DA4A for ; Sat, 27 Jul 2024 17:34:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CDED6B0089; Sat, 27 Jul 2024 13:34:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17EB76B008A; Sat, 27 Jul 2024 13:34:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 06C466B008C; Sat, 27 Jul 2024 13:34:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DD47A6B0089 for ; Sat, 27 Jul 2024 13:34:11 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 728251A0429 for ; Sat, 27 Jul 2024 17:34:11 +0000 (UTC) X-FDA: 82386231102.13.B1248C2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id 1CC3B80013 for ; Sat, 27 Jul 2024 17:34:08 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=d1FzqFtg; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722101611; a=rsa-sha256; cv=none; b=uRwUs8JVNV56DYq5F9MCCssCkR4XOYKh9aVl2STB+GiecTp6yZNmr7gU1FBS+r+6c5tARE ldVRbwAPb7+MACeqhjJVUV/d0uEWxCyPFB1/5y1igvSRXpJeXCi0E1I9hcmRCz5bP2wTWH xTMa/BSPENpi10RCtqneZ4Vpq/f8kmQ= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=d1FzqFtg; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722101611; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HS0ksnlZL3s+zWv6Trq4NFtCnIvD2qUV6Wcs5vzw3ZU=; b=BDMyPUi8tfQJG5vUBywLnjxkxWtisY/UxOGrqWNWKOJg+CySzAjdYtYgJUHCWUwfnVr4py PyvJyKy7thP7+G0SHvQJTe4W6iJQ7ziCq6PjfU6m3Hu3uXTjt+J7aSeykqZA+gIMXSagRA xg2L9PEXuYD3nCLK1x+gv1AM6f/7yag= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=HS0ksnlZL3s+zWv6Trq4NFtCnIvD2qUV6Wcs5vzw3ZU=; b=d1FzqFtgfXrP5irXlBrEXa1BIA nrWpyGGNox3Y89PGNJn3SEM+ZBNR4umAz2dqT6IUYndgXGVACQuPZil0rRg070ZPPtxvEw98FHbqh Vk2TJsJFUPouhKFuDdV0KI4fIWKln2kK/cTVZnHzscD8lhL2U/a4zRCBWnpLsIrOR23QlzgjUvzKH jcIlAGqXYLY1lnuZk8YR7RIkDHS69i5wrMyQWuIsq5n9Itf2/eIv6WpxgL7nL+jvKlbUg+yPyhnrz sNpGeVDYycFu7OBSnVVyddwVrVgTcRKFn2zGWGLbr++LAjQeouRTL4Zqub1clG5XWYT0esIeKdQNa F70V5g9A==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sXlIn-0000000BYCn-1k0c; Sat, 27 Jul 2024 17:33:53 +0000 Date: Sat, 27 Jul 2024 18:33:53 +0100 From: Matthew Wilcox To: Linus Torvalds Cc: Lorenzo Stoakes , Jens Axboe , David Laight , "linux-kernel@vger.kernel.org" , Christoph Hellwig , Andrew Morton , Andy Shevchenko , Dan Carpenter , Arnd Bergmann , "Jason@zx2c4.com" , "pedro.falcato@gmail.com" , Mateusz Guzik , "linux-mm@kvack.org" Subject: Re: [PATCH 0/7] minmax: reduce compilation time Message-ID: References: <23bdb6fc8d884ceebeb6e8b8653b8cfe@AcuMS.aculab.com> <902a9bf3-9404-44e8-9063-03da3168146a@lucifer.local> <137646a7-7017-490d-be78-5bd5627609c3@lucifer.local> <36aa2cad-1db1-4abf-8dd2-fb20484aabc3@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 1CC3B80013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: hh4617usc56xiq8of55wstawpm3o4tra X-HE-Tag: 1722101648-697223 X-HE-Meta: U2FsdGVkX19liZC2jWqR4QBzOakquKWeqvzKW5uHn5fPaWcrUWM60ghV71jRb0vxrW8l3hxm/HQWyg1yJvza884UEACyNbm3Oce2z2fWLp+1dQMbsKf2P1SmXe3F74qXq88k+oGy+87i72gMR3GRuTPosO+1OpyyqnPfi2kWYMSqpAEaivm4MIuJm9NtYEmDk0prxD8zEq3JrpuxNPOGuq4PXssfSec9G6w7jRVY8b4YZjfidHozy1XKvXZwxSKNrF8IBUMaquodVBF5n8sBxGld9E/ttG74ZML4nQaNSTONQiAJJW2m5O/H/7VpU3xUWbAi1U9eOw8S9MZ42HVccwM1q0ZnlY97T+lPzgsyENHVkBKOdI51by7OrGxtEXzrtFEarmIKgzfvBZpKDFhbfJM3kZe6lAnvY3RnXqYTBnMu8t58nwSevRZ+n3Ve6U1w88eSHWv4EILZaiKu8bMr8tWBXPX2V5d1SEtPVYzQJGkhWP3FBjE9HO3X1kkWpuEBuCZzJme7kBIuDP5IpFIY5dEZkKHMXuPEVXkDzh9e4WCMnlX37LaEs2k4MYktgFoZQty5Sng/KDg+JJx8YnGUcnAyQSef7O74QQKRSbX3Mka5kGLRVMuGDkJcQhEYgim+YT+aOanAnNec8x2QqA/hS0io/82RQswxIFcZR+jTsTmVKvUv4MX+4B0vlHExPzKdzhuAPCoqXMfhnmofeAGW3K3QVQcZ0WuzvGEuXQXd/x+8MWXHS70YLYn5v/EKgpFqz3cPE5W24Mn+68AziNyjo4LXbP3zop0DS3D8a4J22VX5d/mwXlDw2OA593gHz/260E6FmcsW24wtZQKL3E3YOpUnH92ZpzFNoXUqCyH2ODiWNwZ8QstUtfSBf+wQesTCsvqWlIrM1MPZeM+ppEhtubvuCkYBLO7UNc0RoIdVpAEhNquknjSaawfKrh77XmENm5hy6vnzzComrcQnTK3 qxDpTlYQ m2B2WRcgarCgf6PpYMhsUQJkgkJ4LKF6jR38ahwD+J/vKuRnFo6oysUTPVRvGFscSrUvN/2QdsPPyK/PQ3ZAYj6JEN+LPfWI/+JXWm1tB8OO6jBcGPWza2vYuYTxPqT3+6+G56AIT98tTYkH4jKSvMlatqflF/vz5/GDUPilQvGkcs8hQXLbdGf3yn44rS+N3zxUL01xpsa+Bgdf7gj63rOaciwckILmdRzsSugksskozsF1hWZstwIaiZ4ZX2ETLvOvLe34yqgo3pg3w+HdZWMHqWONF9j/QJ4kNWLHQ9ccLqycm0NAloc43moI0lhUdHkXO 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 Fri, Jul 26, 2024 at 09:13:11PM -0700, Linus Torvalds wrote: > but while that is certainly an impressive 82kB line, we have some good > company in code VM header files, and I've also seen > > Longest line is include/linux/page-flags.h:507 (27kB) > 'static inline __attribute__((__gnu_inline__)) > __attribute__((__unused__)) __attribute__((no_instrume...' > > because the expansion from > > __PAGEFLAG(Locked, locked, PF_NO_TAIL) > > does indeed generate some impressive stuff. It's all the functions for > the locked bit handling generated from one line. In the specific case of PageLocked, that can hopefully go away fairly soon. We only have 24 instances left in tree and five of those are comments/docs. The ones in fs (btrfs, crypto, f2fs, ocfs2 and pipe) should be converted to folio soon. Mostly they're just detritus. We could probably remove the PageLocked definition in the next merge window if we actually care. But I have been wondering whether the way we define all the functions around page/folio flags is sensible. Every file which includes page-flags.h (... which is most of them ...) regenerates the macros. You can't grep for the definition of folio_test_locked(). There's nowhere to put kernel-doc for folio_test_locked(). Would we be better off generating page-flags-generated.h from a more compact definition file somewhere, rather than using the C preprocessor?