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 0A135C0015E for ; Mon, 24 Jul 2023 09:55:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0F2C280008; Mon, 24 Jul 2023 05:55:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C034280005; Mon, 24 Jul 2023 05:55:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 88736280008; Mon, 24 Jul 2023 05:55:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 78773280005 for ; Mon, 24 Jul 2023 05:55:12 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2872AC09A2 for ; Mon, 24 Jul 2023 09:55:12 +0000 (UTC) X-FDA: 81046047264.26.0BD4D8D Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf04.hostedemail.com (Postfix) with ESMTP id 987CB4000D for ; Mon, 24 Jul 2023 09:55:09 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690192510; 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; bh=DKoKq4sYFY78vZ+z9m2yN0C8Nk6sYvJ9y268+BZaWhg=; b=Ye3G3pOGhMnsR1G9Yj9LTtN77B0GzMoG5Ej5YlV+g6HxFlKvGDqcpNcVThAgS2sPiHwAMz n44qUfoeYORclgYoBN0SHDo5rbS0wnHUl3uw16uH0r28NhBg23cwWcHb3sxHe0q3Az3cv6 PagjHZy01hGT5pYHVUTymzEF80KGaU0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690192510; a=rsa-sha256; cv=none; b=BfiZEvGmL6MW46t22oX0q/h3rPE3F4h66S7rbBsKWAz1bX0ofb04UWA/2IQl7hlAggJI+9 dDglFddF3CHwpVDfp0iIwXo/hZuqOTYeXVoW+7UBlVVY4Tj0X3woZZEBLMXnU41S9M4sxb jDHI9YtxeCYCnyrxLwYRB+koEORtcHs= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4R8b570dplz6GD5T; Mon, 24 Jul 2023 17:50:51 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Mon, 24 Jul 2023 10:55:05 +0100 Date: Mon, 24 Jul 2023 10:55:05 +0100 From: Jonathan Cameron To: "Fabio M. De Francesco" CC: Jonathan Corbet , Linus Walleij , Mike Rapoport , , , , 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 Message-ID: <20230724105505.000060c7@Huawei.com> In-Reply-To: <20230723120721.7139-1-fmdefrancesco@gmail.com> References: <20230723120721.7139-1-fmdefrancesco@gmail.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml500002.china.huawei.com (7.191.160.78) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 987CB4000D X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 46ks6asgr3fk6nsw8oxsakrczkfpm99y X-HE-Tag: 1690192509-24400 X-HE-Meta: U2FsdGVkX19FkhCIKBvVn/PKYifzJKd5N1ecncSWXf0LWw8l8PwzfWNLBOwuhkORMz1GrWwV+m97AgFrIzZoynsmgybZZeJ3YXO1kBzVF7gHyd5FihOS8SE/wa8e7QkahxyZETf42C+E0UM8tF9dCM8z9vqp0/j9ae613nepg48SyF7fXDh9cBdmac65Acj7uCvGB6LwPNEJx1t8FQevNjkGqR/xOeF4/HuY0qI7VWckxbdpddCfn54QUkS2rYWLk6Lrll3ZMSOdZDd1fa7TVBcWBxdgyAU9LA+C7PEFjgMLPLuN++C6BZ3FIVpD4+Z7nb2x+a3FgIXjvk9ZBPcfoDInwQH/vitbCNZml4AbuAOeCSK8g0gGcUEzNrn1uZJxGbkZW65v56E/M8OSWmFlQA9DrhMDdqo7jLiDOMHPILAjJDc1AhesPbMM2tkj/TUUChsxjDLWhpnwbVoWt4lnRigZ9CgWLsC/6q8MxAew+iazMvx8si2m2j30RB67EL2ZBXTbVoxX7ZpaOKCG7oRMG3QwV9NNYFyZVTyDhbff3615MjQbhIDN1lLMbvVOrC8m7JsvtAyKt62mioTKakTUv4cc7KObh3yG456bgPYjRr0fpORkb5tCn6xwhL+a5z3XEA7QVNXTa0qcD80kGCq1atzwt3sf6Iw4GNpe3zqAwzveiF3757I02ej87RJIQ4vPlueypnbT6XG+Xl1oy2vCKS8NWqCDiBLUaOLOiGdzrmL4j64xTMVONCwj0ZKPwIp2xGwDALTebkMJzE88uPhbvF6wufzoR2hiXvYD7RtIAfi8tyvPR5JZMio1KwNqx5VCql65y1HLvuqnTboeqgCj1AAmmno9SJRjVYnUoexj30lAr0lNx3sEsQL/Q+GXwjv7RtY4PTWUA/iJgKODKzW0GnoPyswsHMa2vwjxPdom80soqmjFq4LVJ95LQ6UWRBPMZkmU9VBKZQ/vKfKC8qo ZMCXTTke Qs1wDU/K563StCbrBD8WavbVxNkFUADVUsJ9q4KXjfv0duPdieb9UVAwFXgt/7ec0duKFZxEoPGnkVxaYk4WSz8SwJEevKi6pBtBjYQx2HQuAshiIzr4hu5hPfE7QmYtIXEQ4KhXxDozxdZPikfMTR+v72GOeKhdvcjv8by8o8lR0ur1bCKoFLhUCpqnfDngX2YkX8cn9d7YT+9Od9IFL1Vdt15huYYkwcYx+BLyR/qcBOItir9rsbk21h+qeGjNO6crGMeNSp/gWVFnXWGavvhcEKxOPsX9xeb+fidrIr/ncQIwHBcwyVgheQQC+La+lXoBwvK4txIwEYfDYtCOCCjY9XLQkRs/zeZ+EapQ2pVIyggq8iYxfjrBWYDQiTP5A3DqrkOU1Bg37L0LCO1DiVY0c7+jTIFRjHfgYXj/EM6npA9NN6rbvnDckCs+Z+7M9n+5/zumWEvuP8rN9LdLT6dqZEpmBr54VSDqEdZLRVwtu08/0EXKJcAVsND0T0xufVJDAzvoEXe0aLiJAhgmb3CCK66DWg4Ut1bruKAjsang1kZhco3ptR4y3eRMzfWwtsmHnoCqWBOKLXdSBOJUUR7oN3oErAKifSqgJ97nqIxAfgj8k3GIV87hTtQ== 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 Sun, 23 Jul 2023 14:07:09 +0200 "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 disable > the page faults handler. > > 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 Hi Fabio, Some superficial comments... > --- > > 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). > > This is an RFC PATCH because of two reasons: > > 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. > > 2) While preparing this little patch I decided to take a quicj look at Spell check your intro text. > 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. > > 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. > > Documentation/mm/page_tables.rst | 87 ++++++++++++++++++++++++++++++++ > 1 file changed, 87 insertions(+) > > diff --git a/Documentation/mm/page_tables.rst b/Documentation/mm/page_tables.rst > index 7840c1891751..2be56f50c88f 100644 > --- 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 > virtual memory manager, will need to be written so that it traverses all of the > currently five levels. This style should also be preferred for > architecture-specific code, so as to be robust to future changes. > + > + > +MMU, TLB, and Page Faults > +========================= > + > +The Memory Management Unit (MMU) is a hardware component that handles virtual to > +physical address translations. It uses a relatively small 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 optmization that you 'can' add to an implementation.) > +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 quickly find the corresponding > +physical address. > + > +However, sometimes the MMU can't find a valid translation in the TLB. 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. 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 happened. 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). > When this > +happens, the MMU triggers a page fault, which is a type of interrupt that Hmm. Whilst similar to an interrupt I'd argue that it's not one.. > +signals the CPU to pause the current process and run a special function to > +handle the fault. ... Jonathan