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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2971AC432BE for ; Tue, 24 Aug 2021 19:45:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0C4C161371 for ; Tue, 24 Aug 2021 19:45:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235202AbhHXTpp (ORCPT ); Tue, 24 Aug 2021 15:45:45 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:37950 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229907AbhHXTpm (ORCPT ); Tue, 24 Aug 2021 15:45:42 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 17OJimCa011074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Aug 2021 15:44:49 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 333F915C3DBB; Tue, 24 Aug 2021 15:44:48 -0400 (EDT) Date: Tue, 24 Aug 2021 15:44:48 -0400 From: "Theodore Ts'o" To: Matthew Wilcox Cc: Linus Torvalds , David Howells , Johannes Weiner , Linux-MM , linux-fsdevel , Linux Kernel Mailing List , Andrew Morton Subject: Re: [GIT PULL] Memory folios for v5.15 Message-ID: References: <1957060.1629820467@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 24, 2021 at 08:23:15PM +0100, Matthew Wilcox wrote: > > So when you mention "slab" as a name example, that's not the argument > > you think it is. That's a real honest-to-goodness operating system > > convention name that doesn't exactly predate Linux, but is most > > certainly not new. > > Sure, but at the time Jeff Bonwick chose it, it had no meaning in > computer science or operating system design. I think the big difference is that "slab" is mostly used as an internal name. In Linux it doesn't even leak out to the users, since we use kmem_cache_{create,alloc,free,destroy}(). So the "slab" doesn't even show up in the API. The problem is whether we use struct head_page, or folio, or mempages, we're going to be subsystem users' faces. And people who are using it every day will eventually get used to anything, whether it's "folio" or "xmoqax", we sould give a thought to newcomers to Linux file system code. If they see things like "read_folio()", they are going to be far more confused than "read_pages()" or "read_mempages()". Sure, one impenetrable code word isn't that bad. But this is a case of a death by a thousand cuts. At $WORK, one time we had welcomed an intern to our group, I had to stop everyone each time that they used an acronym, or a codeword, and asked them to define the term. It was really illuminating what an insider takes for granted, but when it's one cutsy codeword after another, with three or more such codewords in a sentence, it's *really* a less-than-great initial experience for a newcomer. So if someone sees "kmem_cache_alloc()", they can probably make a guess what it means, and it's memorable once they learn it. Similarly, something like "head_page", or "mempages" is going to a bit more obvious to a kernel newbie. So if we can make a tiny gesture towards comprehensibility, it would be good to do so while it's still easier to change the name. Cheers, - Ted