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 2D3A9C41513 for ; Mon, 24 Jul 2023 11:21:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 78C3F6B0071; Mon, 24 Jul 2023 07:21:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 715A66B0074; Mon, 24 Jul 2023 07:21:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58FF28E0001; Mon, 24 Jul 2023 07:21:49 -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 404E26B0071 for ; Mon, 24 Jul 2023 07:21:49 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 68D47C0A13 for ; Mon, 24 Jul 2023 11:21:48 +0000 (UTC) X-FDA: 81046265496.05.EC91860 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf02.hostedemail.com (Postfix) with ESMTP id 4B6DE8001B for ; Mon, 24 Jul 2023 11:21:44 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="XSeQ/loM"; spf=pass (imf02.hostedemail.com: domain of fmdefrancesco@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=fmdefrancesco@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690197705; 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=TFhFWl3vFXI5sPJ8FjP5qyAt2hWCbzGdgcfHzMXY7QM=; b=U0QRpTT1p1bjG8hH1iqkU23vyxDiaHGwFeJr9N4G5SyFSYgMsfnRs2MCe/jvk2BVltpmlz uvjFX9x9HhdzYZkCh2FYI0IGa434hmHk5BJFIKd1368TRMvDxXwq2cIJoBwsTzrESbg9hN kevBNF8FkWif9ZlyAaODwB4wzZ6g2kc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690197705; a=rsa-sha256; cv=none; b=xR/IEZK2WtarGWF47nrUSAfj9MVvQXmpLAdp+8U8oy5xp7aOogTTulNuuHb+DYGrNiPy+U OgZMgxwEaEB8gEjr3d2rp1PQNiT0XO/BirTNf+VjBdj2R/HU4DIGe6ZddDe9bjaMDK2JCp nMJjp5xwfoepdrdvO2N5g14bDzwqFa0= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="XSeQ/loM"; spf=pass (imf02.hostedemail.com: domain of fmdefrancesco@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=fmdefrancesco@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-3fd0f000f1cso26057615e9.1 for ; Mon, 24 Jul 2023 04:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690197703; x=1690802503; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TFhFWl3vFXI5sPJ8FjP5qyAt2hWCbzGdgcfHzMXY7QM=; b=XSeQ/loMiS/JX1qZ4jbdZ53R3soRSnaXmc8nlgDRZ+PNsTA++w39sG5vMl/xSsAic5 Bye26XiWAeiro/xUINpaMvvwabcjrDT45tNUwVf0yKfFOUWGcgIPw/6wTry15Tc6AFSQ JLlaSYj/4wM0oWyZFWEaZ8E/BtB+XjCkUnu91+Esnm6knDrmdhXoyzbUM5TUGpKd/5gt kP2VLUnHctEEzfxCGUivrjIFyLImw3EZ9U8M9wTh4ZDFpGyTdybibvPsn2u1RpYulosK taDGeM2M+Fyx4gd1R0p4XmSkwlzrFjwDOaw0nFG2xCGDFWI9hWDPzGXepI4K72KJx144 Ctmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690197703; x=1690802503; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TFhFWl3vFXI5sPJ8FjP5qyAt2hWCbzGdgcfHzMXY7QM=; b=JAzgOJpRalmN9LDlfDf4C9AOJ9gNCtr9L/yYiX0ikTZYjz/nLNz0MWqqwYv/4mxaU1 lMOhF1f5foGnKvo2u1klObRLgROgYFZvb60xPfQ0bKSqNYWskEmkoC8quCSZNI6Tfn/2 isvVtiunuSyJZr3jaFeoXvaj2BtHUhdPo/Tn7rtffgnbIqGs7qOG54SZcGwYF3fHjyK8 X5mUeko61hg9VdwlzmdlFo6c5t0LJaL42y6th4W2pbUFkjiaYsqxI5JlRwq54zfE/80F C0XRLvPNppww7elRSzR7b79SM5ZAyajUzXZw8lHAidY4j/665HvdSZcy3Zn0YIQmkPQf sHxQ== X-Gm-Message-State: ABy/qLaxhL83JoNqJ9iHWrb6YsDY6Vj4JwV7EU0qM4GD5Ih7LnkbJNkg NWO09URTV6HTJB4OVOmzQEQ= X-Google-Smtp-Source: APBJJlGgSiV3HlEbJ70IaPI4jigHZPogdp1chytFPFwub6+Z681rVxLwfJ+8C3bskxVT1+lbFSRzDg== X-Received: by 2002:a1c:6a0e:0:b0:3fb:acbe:da5d with SMTP id f14-20020a1c6a0e000000b003fbacbeda5dmr8130689wmc.4.1690197703191; Mon, 24 Jul 2023 04:21:43 -0700 (PDT) Received: from suse.localnet (host-87-20-104-222.retail.telecomitalia.it. [87.20.104.222]) by smtp.gmail.com with ESMTPSA id l8-20020a7bc448000000b003fb40ec9475sm10059915wmi.11.2023.07.24.04.21.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jul 2023 04:21:42 -0700 (PDT) From: "Fabio M. De Francesco" To: Jonathan Cameron Cc: Jonathan Corbet , Linus Walleij , Mike Rapoport , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Bagas Sanjaya , Ira Weiny , Matthew Wilcox , Randy Dunlap Subject: Re: [RFC PATCH v2] Documentation/page_tables: Add info about MMU/TLB and Page Faults Date: Mon, 24 Jul 2023 13:21:40 +0200 Message-ID: <23157760.6Emhk5qWAg@suse> In-Reply-To: <20230724105505.000060c7@Huawei.com> References: <20230723120721.7139-1-fmdefrancesco@gmail.com> <20230724105505.000060c7@Huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Stat-Signature: m6y8m1mgtun6uzsey6igquopj4epkixj X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 4B6DE8001B X-Rspam-User: X-HE-Tag: 1690197704-637729 X-HE-Meta: U2FsdGVkX18RfTBizUcE9/aTcwV3BLM5tXtWTBru88S5fI1hQ0Uyt5BymTa00IImYTWI+M/rlGRb0ajtBPvPJcJxvTz2PXsQZpJ8A5A6uTkT6z8HWaMNRqqRh9/R5kNjesyleMsLbhLblLniu6UVbisO6hbz6IMv7d14j3Hwt8sOJlcLTrV3KE1URfF+tUwCH6T75WxRYDTBKh0bd1BBbdmZ0WaLV3LjP+rrzAALqMO9xfjmIl/xOfJs6i20X+aASKR3m9GBPdW/W01egBoICCDbP1VZ8pxornA6tBmSFgxj/kU7J77IJzv04BSzsvBp10l8bXMsVkh59W1RiAoFUqb4k5I5tNdbhJWehi6KqUfCG7kU9Ogk73FZVzdajd1H/cCIzzFL04A24ouAQ6Tm62exfaR4xB0akW2c1TqqMGds/cqcvOaAZGgTN91qQufTJ70AcFdH6vO5hLuamJ2T0QxYoQySnu1XvHyOmITWYvfeH6QAJEZDLhP08YFTZbejpEutVEapXXBa4PR0HzpzJ8bY3xUF0s7g4N9gtxHLNiBZBFaE3LTSDPJfROCsxKNqODdFr8jrf8PiC7AF1Y3C0G+djztnRuBlawXt6nlztkNdF+cpPJfSW1juEYG7uPWm3tj1l420XOgfQonFOl1yGmX6lItUOgcv89PDoIO3F9BQ2Vp0GC8Bf6Pvg09iSlB4LHHkjvVx2BNXZg8uRfcBMxCUsAkyUVpEZiVWihdKinfNjlBdyzj4NGRrECNIplgGhqYFvS82mItteITeIjBFznHTPlQ8CxoV4hdFK1LQxMvCLIvh3zItycps8RBltfuj3CloMSmaTYplwSCeKpFG4fpIqWzjMVAoxSv700Tvh6bJw3fzGnToQLDNokaUybHoLp6E2ZfQlDJY64reZsw78Ncp/tx8dGkWTY6/RYvKsuSxjKdPjTajFH2ffDEMqIhFk1cpPpckDKUNYj2vjUS UxxPzaQb fOgBFA2BAr0UyIluc+Z4LyM3HPkkO0Ws6lnFVqLxZvbYy9hkQwEHKsrNQEe/Q00jkZI4klpHxVUx952NynqmO/zeoSmyTj2i9EYD68EzQTeFHONrE8jdThRANWBeiT1N64SNMtyK8cX3vCu+MnT5oKuGadu7VwWw9ONWrdMwzZvYpLOT9422GWrdn4mB0OYnQAzKcoCy+jm8XJU92yDpamIpk4ytwokW7tVpFQnUiPw1iVsmjeOXrtpC/wooEPaDeJ0S7/6CRL1veTGH8g6cdbZ6M/1Riat0pUogytqe4j9NOY1lW6GqSALQVhmPDgF1hNLUziLSBefYERbXg5awGVXf7fD6jwIcLMG5HlfcofrGu4gSMUIXd/784sUPP4Ww4DVthZjVb7IA+3gtvZrm5YcpHh3AMWtkaye9kvQ0C0iJ1vaHkLRdn6dTTSiIRItPv9spB/lM+t3zjr9Wh5EndDY7QGKhJdoCTbw3nTSA4gJSn63gujPMit9nt9eMwye54sDq7FGBqu5lpulzwdC82lqUyxEV1DxQ1bRVPQgmzI44WAmEWjhghZultYh+w2ThIHxUtgURavYqyeH833GL/G8iX1DsglxjJIxL/+VJ+4N3D32jfLSP4jSLj/p8Kd3J5bnIvWu6WT405CmQ4G5BPQXBOtFyvYT++FIIMHaYGu/b1cDSac9PxBraIdxE41Z3JgZzzmI7q2VgTW4b1JEMhji17SFgiQkakTg4n8GUiEeM9NXm5CdPktUaamvEhw6sUC56vljLVhxGRgEvwThCZltOrdh1APiZUhZQZDK5cuLaxhtZTuvRVd6FnSKXvfFVHqdSsUfLaxjJIZ6+LPJJJ46U83A== 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 luned=EC 24 luglio 2023 11:55:05 CEST Jonathan Cameron wrote: > On Sun, 23 Jul 2023 14:07:09 +0200 >=20 > "Fabio M. De Francesco" wrote: > > Extend page_tables.rst by adding a section about the role of MMU and TLB > > in translating between virtual addresses and physical page frames. > > Furthermore explain the concept behind Page Faults and how the Linux > > kernel handles TLB misses. Finally briefly explain how and why to disab= le > > the page faults handler. > >=20 > > Cc: Andrew Morton > > Cc: Bagas Sanjaya > > Cc: Ira Weiny > > Cc: Jonathan Cameron > > Cc: Jonathan Corbet > > Cc: Linus Walleij > > Cc: Matthew Wilcox > > Cc: Mike Rapoport > > Cc: Randy Dunlap > > Signed-off-by: Fabio M. De Francesco >=20 > Hi Fabio, >=20 Hi Jonathan, > Some superficial comments... Maybe that they are "superficial", BTW they are indeed very welcome :-) > > --- > >=20 > > v1->v2: Add further information about lower level functions in the page > > fault handler and add information about how and why to disable / enable > > the page fault handler (provided a link to a Ira's patch that make use > > of pagefault_disable() to prevent deadlocks). > >=20 > > This is an RFC PATCH because of two reasons: > >=20 > > 1) I've heard that there is consensus about the need to revise and > > extend the MM documentation, but I'm not sure about whether or not > > developers need these kind of introductory information. > >=20 > > 2) While preparing this little patch I decided to take a quicj look at >=20 > Spell check your intro text. Sure, I'll s/quicj/quick/ > > the code and found out it currently is not how I thought I remembered > > it. I'm especially speaking about the x86 case. I'm not sure that I've > > been able to properly understand what I described as a difference in > > workflow compared to most of the other architecture. > >=20 > > Therefore, for the two reasons explained above, I'd like to hear from > > people actively involved in MM. If this is not what you want, feel free > > to throw it away. Otherwise I'd be happy to write more on this and other > > MM topics. I'm looking forward for comments on this small work. > >=20 > > Documentation/mm/page_tables.rst | 87 ++++++++++++++++++++++++++++++++ > > 1 file changed, 87 insertions(+) > >=20 > > diff --git a/Documentation/mm/page_tables.rst > > b/Documentation/mm/page_tables.rst index 7840c1891751..2be56f50c88f 100= 644 > > --- a/Documentation/mm/page_tables.rst > > +++ b/Documentation/mm/page_tables.rst > > @@ -152,3 +152,90 @@ Page table handling code that wishes to be > > architecture-neutral, such as the>=20 > > virtual memory manager, will need to be written so that it traverses a= ll=20 of > > the currently five levels. This style should also be preferred for > > architecture-specific code, so as to be robust to future changes. > >=20 > > + > > + > > +MMU, TLB, and Page Faults > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > + > > +The Memory Management Unit (MMU) is a hardware component that handles > > virtual to +physical address translations. It uses a relatively small=20 cache > > in hardware > It may use a relatively... > (I doubt Linux supports anything that doesn't have a TLB but they aren't > required by some architectures - just a performance optimization that you > 'can' add to an implementation.) Oh, I didn't know that Linux supports non-MMU architectures. However I susp= ect=20 that the vast majority have MMU and TLB. Is it correct?=20 I'll change the statement to "it may use, and in the vast majority of=20 supported architecture it indeed uses [...]". How about this? Is it not yet= =20 what you meant? > > +called the Translation Lookaside Buffer (TLB) to speed up these > > translations. +When a process wants to access a memory location, the CPU > > provides a virtual +address to the MMU, which then uses the TLB to quic= kly > > find the corresponding +physical address. > > + > > +However, sometimes the MMU can't find a valid translation in the TLB.= =20 This > > +could be because the process is trying to access a range of memory that > > it's not +allowed to, or because the memory hasn't been loaded into RAM > > yet. >=20 > It might not find it because this is first attempt to do the translation = and > the MMU hasn't filled the TLB entry yet, or a capacity eviction has=20 happened. I thought that "[...] hasn't been loaded into RAM yet" would have covered a= ll=20 cases comprising lazy allocation, copy-n-write, and swapped out pages. I=20 talked about the first two later in the text, but I forgot to speak about=20 swapped out page frames to persistent storage so I'll add it in the next=20 version. However, I am thinking that is not the TLB misses that may cause an excepti= on=20 to fault in memory, but it is the MMU itself if not able to fill the TLB wi= th=20 the content of allocated page tables. If you confirm so, I'll need to rewri= te=20 the first introductory paragraphs. Can you please confirm?=20 > Basically failure to find it in the TLB doesn't mean we get a page fault > (unless you are on an ancient architecture where TLB entries are software > filled which is definitely not the case for most modern ones). Let me summarize so that you can confirm or deny whether or not I=20 understood... 1) TLB misses don't cause page faults unless MMU is not able to find the=20 entries in the hierarchy of page tables. If it finds the entries is=20 transparently refills the TLB buffer with the found translations. 2) Page faults happens only if MMU, after walking the hierarchy, cannot yet= =20 find any suitable translation. > > When this > >=20 > > +happens, the MMU triggers a page fault, which is a type of interrupt t= hat >=20 > Hmm. Whilst similar to an interrupt I'd argue that it's not one.. 3) I shouldn't define it as an "interrupt" because it technically is not. H= ow=20 about "exception" or "software exception"? =20 > > +signals the CPU to pause the current process and run a special functio= n=20 to > > +handle the fault. >=20 > ... >=20 > Jonathan I don't read any other comments on the second part of the RFC. Does it mean= =20 that the second part is OK from your POV? It would be of great help if you could set aside some more minutes and clea= r=20 the doubts I just expressed and answer the questions I asked :-) Thanks for the comments, =46abio