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 3B0AAEB64DA for ; Wed, 14 Jun 2023 07:12:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7BE66B0078; Wed, 14 Jun 2023 03:12:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2B546B007B; Wed, 14 Jun 2023 03:12:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F3D88E0002; Wed, 14 Jun 2023 03:12:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8D5186B0078 for ; Wed, 14 Jun 2023 03:12:27 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 646D91407FC for ; Wed, 14 Jun 2023 07:12:27 +0000 (UTC) X-FDA: 80900485134.06.A756285 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf27.hostedemail.com (Postfix) with ESMTP id 9A8CD40005 for ; Wed, 14 Jun 2023 07:12:25 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=yAKVXLzw; spf=pass (imf27.hostedemail.com: domain of linus.walleij@linaro.org designates 209.85.128.177 as permitted sender) smtp.mailfrom=linus.walleij@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686726745; 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=AWHbDUIB8U+qtgrSoFxR3VEwuBtSP2zu4dnUABc1wvE=; b=3oVKFJEz0jQ6F0jkAmYj5qHBwyMWvai/Ag9OThb85SszzUt88GhMC7+joVU+Ql0zpU82fN N/QkEDNv7/B83aYUBohCYwVUBKGFgQ1GB/sLnvq0ufKiEn6eR1pf/3zx+DZmt4s7Q5qRgl WaqciVQHtBPEvmLOdDjrLQkjm7QTGdE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686726745; a=rsa-sha256; cv=none; b=2iiysnR3bqcufgt/3gbHveznK7zHLQjtx+zo8UfVbd6qcncLa6RBS0jyofyhFhS035RTNg f2oNZmO9WikKQOskGxTLI+MzJce2NJgrq2efnoCd5tqUsMOGsD2h/d10GzHOtRATLGaD/p zrxmdxZSzHU3Ce69tgguKXCx/d7279w= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=yAKVXLzw; spf=pass (imf27.hostedemail.com: domain of linus.walleij@linaro.org designates 209.85.128.177 as permitted sender) smtp.mailfrom=linus.walleij@linaro.org; dmarc=pass (policy=none) header.from=linaro.org Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-561b7729a12so4791797b3.1 for ; Wed, 14 Jun 2023 00:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686726744; x=1689318744; 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=AWHbDUIB8U+qtgrSoFxR3VEwuBtSP2zu4dnUABc1wvE=; b=yAKVXLzwY5/bo3MapGalo/VmgpZhXPFzARCopGZQH1dIFiIRMsz2HLdGC384K+5VVs NmfxnOrpOCjHtsd4qE2m89xz2aPe5WKjQ8UALL80ptcTFn8W4XweIly80WPKALOJMko/ /tzNsManeqVF/JCNKAEOaN6ztEClHDkpBNScnxionCtKtL1wqih/qcb7WXhhpJnl+yFp z5Z2IYSvPtRlh0YEkIIRl7MjX/D0LEA6qNP2IRZ4ahsY9E5mb/NJ4oXMo3EM3Qenc1ty dBCB6ojG/mC0Ueh8keldvhRzxfRWT4oKcUV2/qZOf/8jPg+uUDyBLgasv8A8O9Gxaotw tFQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686726744; x=1689318744; 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=AWHbDUIB8U+qtgrSoFxR3VEwuBtSP2zu4dnUABc1wvE=; b=lgtWQLhbRwmDu9lTq+SRLBx0BTr8Exwnytk+wxfWG2rZk9KAIga+HuJuZyClmyC9um mtoHLoqXPaJLe0F3+bpmAWjaID+y7Krlpv1B4on7B8+UaFtYG98w4ryUNF/XlRuATudt +a4x8lPk6Boath74X/+dbTjnA7b+XEYg7TV0NvGNfvuk5JNmenRVzCWq4+5X+GXtQ51W qJVjrJGue0mCSVQYPgciTji0pXPsS0q2/63TliTcGIUE13SfHPHoIJpQ4mjCGXqGiDsK /JqSOMrfzUhbRj+GDkyrO3u5JLp6GjcGhzRh4Uq9Lx0wZn5/LnkDSb2PttCpszUfe808 gukg== X-Gm-Message-State: AC+VfDyRy9W6euYAEBYyg9QqrEZ7/SPolvHr2qwlB6aUxOug2y72l6d9 qjR7YoRtnQ5ZEVg7d+d0AeoteDx5beFFjInIZ0uIFA== X-Google-Smtp-Source: ACHHUZ4Ay9jY6iCOsAGVFKmaIHQT6ZQsGm25F5VYaPHt8JoX8//CV2rAJFvPTBsVOOEJ4H52hEtVwe8Da5FE9B1phwI= X-Received: by 2002:a25:4150:0:b0:bc5:16ba:aab2 with SMTP id o77-20020a254150000000b00bc516baaab2mr1132838yba.1.1686726744607; Wed, 14 Jun 2023 00:12:24 -0700 (PDT) MIME-Version: 1.0 References: <20230613083906.757878-1-linus.walleij@linaro.org> In-Reply-To: From: Linus Walleij Date: Wed, 14 Jun 2023 09:12:13 +0200 Message-ID: Subject: Re: [PATCH v4] Documentation/mm: Initial page table documentation To: Matthew Wilcox Cc: Andrew Morton , Jonathan Corbet , linux-mm@kvack.org, linux-doc@vger.kernel.org, Randy Dunlap , Mike Rapoport , Jonathan Cameron , Bagas Sanjaya Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: qd55k6fdc47xumgadz98iutgn76w8ej7 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9A8CD40005 X-Rspam-User: X-HE-Tag: 1686726745-101714 X-HE-Meta: U2FsdGVkX1/fuOvwHWkPw+LqKfFfukhCS5NuK/lpQtM0eptfKnDJ4GI7xt5HkE/XJbI+t0Ol/63m+LabECETeljvg2hn5yjkVw4eJ995b0I455SDDWFq24oWvjbtMPF5WKfB5ieO4BUw4WdCCv/9EtO/+qINdahLkluSOVH+N0OVTXEAE2aalbLF7ysIHirRuWl7Vuc83uYM7MSxvEyvC6vL7EwmpAzEB38tAI7pxYtF8vEHr7FjwC/Akx+FXjagp4SuIyTNnbmmA8Fjzx4RNU2x70LyxK6XRiHCEo3164rI1gRc/aiVvGUNOtGqSIo4tOOvh0J9l1w9GxcgcooiH5YAs1phlQ8jcxSmEWI8aGVGvI6yi/HPrMbiNO+X62nteMZ2kA5BhMrkNw7e7Zc52qdlbwWrpjvd7jy4/QqlaU9gZd1VVBvfl5xhdrHYfh0mXMYV84lfVy49ST5Pq5V9j2CxhNiB9bPxMxlnDS2GYbhmdDp2tUslBOWdoIUYzVtyj/hlVc25lDOB8wMdXfqDmXR5remdGWH6mwz3pVR6dkakEgGNvnHP4N2mE0ohiQ6pQn9LzKO12KtcKDV1qFZjVcAkSL4b8hsUULe8xdWryEzKGEeqp8RiY54j6Q0p0B+h5pbE+gOL6KsmFFNSOU2XlONN8uF+CakH0aaFrVnPhnauKUdJE87MhTKuqsLYRMc6JL/l07MQwHG/1p73RIOOfA7TPHUWsUdgWiydN+W7UEwzYnO5V59rC8IC0X9406x2choHO/ahgiuZmG4R2XyCJ9LPMkc2EjOAjL1QPPizJmDiBjtiUN4Uz7Wzb3b3TzrnLMakES6LAqMq2ZJmVRvtGv3Nlc4wSqLkIlE8d59IWRgL1dZjgjGTCtuCdrmqXIoMorj31aePiU7FYrB/v/qjLnqeXNZnN8BYNssF0IrGmu7xn9TSfJd/Q8Xs286osCcKgSVmFuRo2O5iZJs8hYK fCfjCH9P GohqqzbeWhATJQLbF4VqFDUOQC4bPsdBntRZCAacczP17PVvUTjJCsA87NBMNAbb9Kq4ZsoWl3QRtYLkicY6CZd5bMVLq/RxnKD+fo70RBYgABDoEGaTHuDqZkbv4743CBavGMfZw/MTSnlhVN7CxdPCl2a2eoF9e2x2oawQ+tM08cpKKFGFyVNE/OvVUvfb/FLXaPwMROKLabcYr1iPIL0QEOkJML6QnAhyKgS1BiJMzjhBLo2p/5fhFjceacDIMCAN6iQTBEjQP+oc43L+OffuZyQ== 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: On Tue, Jun 13, 2023 at 4:45=E2=80=AFPM Matthew Wilcox wrote: > On Tue, Jun 13, 2023 at 10:39:06AM +0200, Linus Walleij wrote: > > +Paged virtual memory was invented along with virtual memory as a conce= pt in > > +1962 on the Ferranti Atlas Computer which was the first computer with = paged > > +virtual memory. The feature migrated to newer computers and became a d= e facto > > +feature of all Unix-like systems as time went by. In 1985 the feature = was > > +included in the Intel 80386, which was the CPU Linux 1.0 was developed= on. > > I still don't think the origin story is useful. It's trivia and doesn't > help someone understand what they need to know. I think history is pretty important for understanding concepts, otherwise they appear as not invented but emergent. However the question about what is important and what is trivia is a question of professional technica= l writing. The documentation maintainer works with technical writing and can decide the value of this. > > +Page tables map virtual addresses as seen by the CPU program counter i= nto > > +physical addresses as seen on the external memory bus. > > This makes it sound like virtual addresses are only used for > instructions. I had better wording earlier, but there's no point in > repeating it. Just: I dissent. You are right I should reword this to be about memory accesses, I might have missed some of your feedback so I will go back and check what you said. > > +Linux defines page tables as a hierarchy which is currently five level= s in > > +height. The target architecture code for each supported architecture w= ill then > > +map this to the restrictions of the target hardware. > > The word "target" isn't adding any value in this paragraph. Thanks dropping it. I guess the word is a byproduct of doing too much cross compiling... > Honestly, I don't like much about this document. The writing is > flabby and untargetted. Please refarain from using this kind of unproffessional wording in your professional communication. Be technical, precise and to the point and do not use value statements. > Much of my last review was ignored. I'm just > going to stop here since I have low confidence that any suggestions > would be incorporated. Your statement is incorrect. Your feedback is seen as valuable and it is read, reacted on and incorporated. I did rewrite the document thoroughly in reaction to your comments, and in order so you feel respected I am going to illustrate. You wrote: > This reads backwards to me. The index point in the hierarchy (what an > unusual turn of phrase!) is surely the virtual address, since the > hierarchy is indexed by virtual addresses. If this paragraph is > supposed to define what a pfn is, how about simply: > > The pfn of a page of memory is the physical address of the page divided > by PAGE_SIZE Which I took as a good suggestion, and the paragraph is rewritten from this (which you criticized): > +The physical address corresponding to the virtual address is commonly > +defined by the index point in the hierarchy, and this is called a **page= frame > +number** or **pfn**. The first entry on the top level to the first entry= in the > +second and so on down the hierarchy will point out the virtual address f= or the > +physical memory address 0, which will be *pfn 0* and the highest pfn wil= l be > +the last page of physical memory the external address bus of the CPU can > +address. To this (current wording): > The physical address corresponding to the virtual address is often refere= nced > by the underlying physical page frame. The **page frame number** or **pfn= ** > is the physical address of the page (as seen on the external memory bus) > divided by `PAGE_SIZE`. Which obviously includes some of your wording (divided by PAGE_SIZE etc). I also got review comments from other reviewers and that is reflected in th= e current wording. You wrote: > Your arrows are backwards. The PTE doesn't point to the PMD; the PMD > points to PTEs. And this was changed to what you suggested, and it was a pretty fundamental and important change. You wrote: > You have rather too many forward references in this description for my > taste. Start with the PTE, then the PMD, then PUD, P4D, PGD. And this was changed to exactly what you suggested. You wrote: > array, not list And this was changed (everywhere) to what you suggested. You wrote: > I think a document like this that talks about page tables really needs to > include a description of how some PMDs / PUDs / ... may not be pointers > to lower levels, but direct pointers to the actual memory (ie THPs / > hugetlb pages). And the document now includes this (Mike Rapoport made the same comment). So your claim that "Much of my last review was ignored." is simply incorrect. It was not ignored, rather it has thoroughly shaped the document= . Yours, Linus Walleij