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 558FCC001B0 for ; Sun, 23 Jul 2023 13:14:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA8976B0074; Sun, 23 Jul 2023 09:14:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B31736B0075; Sun, 23 Jul 2023 09:14:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D3496B0078; Sun, 23 Jul 2023 09:14:29 -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 85FA06B0074 for ; Sun, 23 Jul 2023 09:14:29 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4F06FC0414 for ; Sun, 23 Jul 2023 13:14:29 +0000 (UTC) X-FDA: 81042920658.14.5473325 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf11.hostedemail.com (Postfix) with ESMTP id 698324001A for ; Sun, 23 Jul 2023 13:14:27 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=f7yYsghW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of fmdefrancesco@gmail.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=fmdefrancesco@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690118067; 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=8W1u2MVpGKLpBiXVuRgUMbIPOpowv0h6POZ4Q69kPEw=; b=OTj9kxvwabICgv17nZCfO2sVOWHerEUQNHtAUWouyPttc0RftBQxfXf8fsAA6Lcnj6j12U xhGd4Bx+RAGGpegmKveFNav/EVpIGZenZC1dSzzx1WI+KIae8ttLyV/D8TzC1aolxUxAMV 2asBdQgnrOoB0C27wnQg8tYSBpGLDRU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=f7yYsghW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of fmdefrancesco@gmail.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=fmdefrancesco@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690118067; a=rsa-sha256; cv=none; b=REjJJCl9Nx6PhzrP0mEgM7KFbaJQNWBLdFoPLNmxx2wYd4AYknDeRUxxHCUhREaz0AIaFh 9eRXA/2Y46QI3sKMNe5eK3wKbvhIypE56uybsNcCnq+C8YeISfP9UVpaq2QZ5q1yyTYQT/ Ppr1kHIjt+wMWKWui/c11VNSxNux+NY= Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-316feb137a7so3026969f8f.1 for ; Sun, 23 Jul 2023 06:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690118066; x=1690722866; 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=8W1u2MVpGKLpBiXVuRgUMbIPOpowv0h6POZ4Q69kPEw=; b=f7yYsghWvl866bYjcCiFV0z7F4z95ARagx3h3TSvgIxiKS4YEl0LSrRGAtpHiAkpk9 btGjehTl5ra7cllW8CwPnkas0KSINR7pY83WV4SnjPIdoHeDmXhhsl6SuiigTbkrx95U o8Kktc79ujFxmmUouqHMc/2hsMw12E+At1OaaGvXxqs5BoqOfmg6StwwQwqItc2U8dY8 WYLQCsxTHqbwp+qggzrkgcoPBQhhEql6IS6B+ShGMOuZ5HkxlmEy2L2q8yLbcGMktk3T +8byXKtHZx9/IPYa+XqMIzpuQMVFE+JQRqh3z8FZtp3jlSDk18+VoDGyxX/s1RaWdp2p JXqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690118066; x=1690722866; 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=8W1u2MVpGKLpBiXVuRgUMbIPOpowv0h6POZ4Q69kPEw=; b=ihjquBiiqFDTAq7mzGp0TctyCBXXLYen6F9Hps/4IH9LOo7Y9oK1kuuXodYoJ6APNg LUsHhhGzfaPOiMuukYopFwyjik7pjfN85vr+IVzAnr/eqQ8QHvMb7bsyjB9KP9oJi7l4 wczwNf28fcQmaZdWgOcuzH3rLrRNtDs2tQMrpWDiRFg7LbI5Pg06jomNOTJJB9IkBPjt /7jnlRdczw+sxz2ssqwJsCaLkk1SUsWhgkf1+JH1mFOmkkpzb6IlYbSKZs+L6pV1klpK 5LlUlXshLWySvGk89GulZFrhFMyxpdPwABzRQZuLdCjY3EsKgmcbrB2d4Xrg2M7NSryX 7muA== X-Gm-Message-State: ABy/qLYRpvwqaZvzJbpYWIi90FlIwS91hCvS2pwJHpFjFSZRP8KbsuK4 UXl4KYBtay6sG3vXGbZiutg= X-Google-Smtp-Source: APBJJlFEVmjwJvqvDE8T2vbcheMra+2GkEuWoZHrWtnjG6aA0Fgss2BDAGlYBjc9BJkKVsMiO7TAlw== X-Received: by 2002:adf:d84d:0:b0:317:4828:89b7 with SMTP id k13-20020adfd84d000000b00317482889b7mr2945320wrl.67.1690118065735; Sun, 23 Jul 2023 06:14:25 -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 b17-20020a5d45d1000000b003142ea7a661sm9740742wrs.21.2023.07.23.06.14.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jul 2023 06:14:25 -0700 (PDT) From: "Fabio M. De Francesco" To: Jonathan Corbet , Jonathan Cameron , Linus Walleij , Mike Rapoport , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Matthew Wilcox Cc: Andrew Morton , Bagas Sanjaya , Randy Dunlap Subject: Re: [RFC PATCH] Documentation/page_tables: MMU, TLB, and Page Faults Date: Sun, 23 Jul 2023 15:14:18 +0200 Message-ID: <4838064.GXAFRqVoOG@suse> In-Reply-To: <20230722004451.7730-1-fmdefrancesco@gmail.com> References: <20230722004451.7730-1-fmdefrancesco@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspam-User: X-Stat-Signature: f7szzw8g8n91xew44copb4j565iie4ce X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 698324001A X-HE-Tag: 1690118067-520667 X-HE-Meta: U2FsdGVkX18+o3T8S/NQ2RnvAokmw22dZ0P+HRM7A41ztz/sAphAXkb9W7hL1QgJ2Sq5SLwVe38mR6UTmdfG02wNQWkAnJ62pSu38Soe7E+H2bd3DoSJbRWvpkuy5kJvSV4L3bN7gBklztaPE1cEgvJPb+1CtifvQ855kQoroTWqeP8N7Ba46HLmXUpDfgT9eOwtAzNJBxHKD2UAO/Z5FWuSERJgyzPH8wEPOVV0d5wNrUeJiIfiLWF0ErkB78T6+Z7eGcZ5Ea9cBuV9P7XLYVXFfCbqpXFiNeSRP4gCyGl/KzD2Y6TecDuH8RWklSra0gy8knYBKkjom7HmQwkcDIYTkCAHDJAV4HIj53ELd7zwbN8qwE4X6p2z8yvULNsqMJyYUYSxkyP+8i3oD2SiGic62VPu/jXGVa6AYR5fKyN4HqmpQharsdefOJy92U1630wWNiVj1Q0yqNP0zILfzyf2+2O3TBAmNLFbyMgtfEm9JEJk4rQNRk612pjB+i7cRyT8DqNXnaDoXmEz95YG4LQ5YnFmMXYJy2t6PA8nimbRorKmI20ndarfjAfEEbYIS2rUPkXVP7hzW0nToIq/F8DqCO8kxMZEZQELag+OQPGNbMe/90j5Nz6DXiNoSAqQ6uSFdGAKNabhH3xHgRYXRx8ARATd48kCMjX1xZO17DigkmG9XOISOLaqE72OsDXn+RzQnnS6Z/PhQv89lnFBX1HsPPcVQpeoOEl3hdZ2sXySzZbOK9/MHoLrb+9Qfzby7Ns42338JJWwfPIgbdFq1HpL3YsvSXsN82J0W+pthsH8yGa8zL2PeOPGKFlPFKik9wRi8VuoTA6jsIOmwR8GdM8xt3KKKlnCZQTScjS8DnP35oP18rIYrhDgDcJbm5ewMP0aZtpWS0jDJcBnI765EayEVg3GopvCARUvcQ5LpPDSq9cIW3EfZtUlORHH8hmqxuFlp3nvQqtGd5ZdmDw tg5TOQj1 Ch0dI1plmropITt6MGOwJSsiLgcAEOtHwNg4r6QOTOLfvIg9PG6SK+BMim9oMnHWMq3uUGRAFrwRFBYE5nvXhs/Xk6BskakeaMLCONR+oSdMpKnKdvKEl4RmuSw2ZIhfaCkyFWFFCALZ1ehlDsCEL0Zh+iztaneUjZuycpuELKpHjK2cuzONl2ZKLHlL6xqn4cw6JDlzvNNyND3V2+81ufgEwD/t+T4ZhRLW/Vnjbb3ubbgMcMLr04sSDMkaEurRnS2fwtGgH7tODRTZLeHwqtaa3lRmbV8IwH5vDg1FfGUa3sYuzZgzfxVYTjRcHzga9wiB+ztrQaRE0WIz8zD9VsLJup0mEJi0zUSb3+sQrM/KF4Kqu0WfG4/IdZHP0keGVSXo+y4g5pq8BTdbOoSKTptHVG0oHkZydvjOE5i6xhslkRkpldVDL69RkJwpr8GAAkQLpI24PivWRVeBtsEJ3Hz94/Fiy2zb+0jHpihQtDK7PooDKDD7d6zjKIMawoKKUkT6aDxa58xsQX2wY6CT80aDBM1crUSUJIhyN4jT+RIgMhdlPPYJXfPUEzjNlZ4tduGyILLmNKvzFFX4tmhlzGFoJKy3h1mWW9W3U1ElRUYImLHKdQ0AtLTwF43aNbOiXk5T5nIpkDZJ5ais3Hv0bAwWYB0LTXxjUIDsOyaSd+EmkWfXR937mnWY63qLR7U1uS5orN2Gp4Y5ReJinrUyG5166vMbNa3ImA/Mx0vAHH648kW2+nW1hSmxxN9AL/mFt5jtZIhwdSgiS1ZpOkvfwwygFVF2AS+LFtoVVUKN2inve/TC6X+scryeuTE8wAj/SY7rgGFZfy5zVffX6ppVOIp3zXQ== 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 sabato 22 luglio 2023 02:43:13 CEST Fabio M. De Francesco wrote: > Extend page_tables.rst by adding a small introductive section about > the role of MMU and TLB in translating between virtual addresses and > physical page frames. Furthermore explain the concepts behind the > Page Faults exceptions and how Linux handles them. This is superseded by "[RFC PATCH v2] Documentation/page_tables: Add info about MMU/TLB and Page Faults" at https://lore.kernel.org/lkml/ 20230723120721.7139-1-fmdefrancesco@gmail.com/. Please refer to the above- mentioned second version and discard this. Thanks, Fabio > Cc: Andrew Morton > Cc: Bagas Sanjaya > 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 > --- > > 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 > 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 | 61 ++++++++++++++++++++++++++++++++ > 1 file changed, 61 insertions(+) > > diff --git a/Documentation/mm/page_tables.rst > b/Documentation/mm/page_tables.rst index 7840c1891751..fa617894fda8 100644 > --- a/Documentation/mm/page_tables.rst > +++ b/Documentation/mm/page_tables.rst > @@ -152,3 +152,64 @@ 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 +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. When > this +happens, the MMU triggers a page fault, which is a type of interrupt > that +signals the CPU to pause the current process and run a special function > to +handle the fault. > + > +One cause of page faults is due to bugs (or maliciously crafted addresses) > and +happens when a process tries to access a range of memory that it doesn't > have +permission to. This could be because the memory is reserved for the > kernel or +for another process, or because the process is trying to write to > a read-only +section of memory. When this happens, the kernel sends a > Segmentation Fault +(SIGSEGV) signal to the process, which usually causes the > process to terminate. + > +An expected and more common cause of page faults is "lazy allocation". This > is +a technique used by the Kernel to improve memory efficiency and reduce > +footprint. Instead of allocating physical memory to a process as soon as > it's +requested, the kernel waits until the process actually tries to use the > memory. +This can save a significant amount of memory in cases where a > process requests +a large block but only uses a small portion of it. > + > +A related technique is "Copy-on-Write" (COW), where the Kernel allows > multiple +processes to share the same physical memory as long as they're only > reading +from it. If a process tries to write to the shared memory, the > kernel triggers +a page fault and allocates a separate copy of the memory for > the process. This +allows the kernel to save memory and avoid unnecessary > data copying and, by +doing so, it reduces latency. > + > +Now, let's see how the Linux kernel handles these page faults: > + > +1. For most architectures, `do_page_fault()` is the primary interrupt handler > + for page faults. It delegates the actual handling of the page fault to + > `handle_mm_fault()`. This function checks the cause of the page fault and + > takes the appropriate action, such as loading the required page into + > memory, granting the process the necessary permissions, or sending a + > SIGSEGV signal to the process. > + > +2. In the specific case of the x86 architecture, the interrupt handler is > + defined by the `DEFINE_IDTENTRY_RAW_ERRORCODE()` macro, which calls > + `handle_page_fault()`. This function then calls either > + `do_user_addr_fault()` or `do_kern_addr_fault()`, depending on whether > + the fault occurred in user space or kernel space. Both of these functions > + eventually lead to `handle_mm_fault()`, similar to the workflow in other > + architectures. > + > +The actual implementation of the workflow is very complex. Its design allows > +Linux to handle page faults in a way that is tailored to the specific > +characteristics of each architecture, while still sharing a common overall > +structure. > -- > 2.41.0