Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp3007112pxb; Tue, 24 Aug 2021 12:47:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWDh6SU275p/jJP8heqfK4mp1Aqf+onVoOLGM+XBj8Bkh5QeLc3o6EuM1LqpvkFOi5qilP X-Received: by 2002:a17:907:12d5:: with SMTP id vp21mr19488655ejb.144.1629834467711; Tue, 24 Aug 2021 12:47:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629834467; cv=none; d=google.com; s=arc-20160816; b=SGiFpm37WdwX4V1B0zGbibPkzdRH06lKOUpidobqBrtdXtiWO5FakKfxTGfhuyf1QP HMAUUaeBxiLb4+LEEbGtL+1y8064ckFGRl4c6Giy9WsW46UtffVfgK99kEaWjaSH93FI /HrzGQBxqqrIVnu+D6UA5AlJXlHgGBwpxSdGUGJyWLiUbgw3Ke9AzevOJjkfwfazKv8b G3eAP1qxFx3NxbbSfpZLJizmB+cCckYAzX79fenQBRQb1IiyBRrPiKtL90roXFBTm2l3 zYTUUxOL6XJqzafG6deHhEoBnrUL7v89UPdcbBYdETsjoHevoL8cfI+kt/Is90ktWmzz ws7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=4v/4EOTUuuFgq/0GyMw8glFnFxVwwcwn8gezs09ZpU8=; b=r+wvF+wLk5Wswm4GXkxc+nkxXYYLT4uKPiIgevwaivDOseOgs5bR3X5vLkeAQoGU9J rMzQhD/zoPAk8i1+GeBIkqNhDCgYIrIQ/HdKwnNvQmANcedsLVbbJW6DbYkvAt7vHszK oJJU+3kYoCCz6aQRHhrPJlq3cr9lPURwxMCS/k2XeC5pjQ7oJIdItXJ6Rl4V+HDWP/xB KyYR5zCLbY9FQj0U1yskoSDQmSr1ttrAXtoUzxmF71JVHjFtV+bySGwa67Sg4cx1JVMw ja5l/uP7nybMEvCuSibf5IuSKyMEntKicEojILh0AD0yiRODlY8rwOgr0QXuJehCC9Fl HYSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 6si23506915eje.315.2021.08.24.12.47.24; Tue, 24 Aug 2021 12:47:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235052AbhHXTpo (ORCPT + 99 others); Tue, 24 Aug 2021 15:45:44 -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