{"id":469,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:18","modified_gmt":"2020-08-22T20:26:18","slug":"this-is-the-page-title-toplevel-302","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=469","title":{"rendered":"Process Virtual Memory"},"content":{"rendered":"\n<title>Virtual Memory<\/title>\n<p>\nA process&#8217;s virtual memory contains executable code and data from many sources.\nFirst there is the program image that is loaded; for example a command like <command>ls<\/command>.\nThis command, like all executable images, is composed of both executable code and data.\nThe image file contains all of the information neccessary to load the executable code and\nassociated program data into the virtual memory of the process.\nSecondly, processses can allocate (virtual) memory to use during their processing, say to\nhold the contents of files that it is reading.\nThis newly allocated, virtual, memory needs to be linked into the process&#8217;s existing virtual\nmemory so that it can be used.\nThirdly, Linux processes use libraries of commonly useful code, for example file handling\nroutines.\nIt does not make sense that each process has its own copy of the library, Linux uses\nshared libraries that can be used by several running processes at the same time.\nThe code and the data from these shared libraries must be linked into this process&#8217;s\nvirtual address space and also into the virtual address space of the other processes\nsharing the library.\n<p>\nIn any given time period a process will not have used all of the code and data contained\nwithin its virtual memory.\nIt could contain code that is only used during certain situations, such as during initialization\nor to process a particular event.\nIt may only have used some of the routines from its shared libraries.\nIt would be wasteful to load all of this code and data into physical memory where it would\nlie unused.\nMultiply this wastage by the number of processes in the system and the system would\nrun very inefficiently.\nInstead, Linux uses a technique called <em>demand paging<\/em> where the virtual memory of a process\nis brought into physical memory only when a process attempts to use it.\nSo, instead of loading the code and data into physical memory straight away, the Linux kernel\nalters the process&#8217;s page table, marking the virtual areas as existing but not in memory.\nWhen the process attempts to acccess the code or data the system hardware will generate\na page fault and hand control to the Linux kernel to fix things up.\nTherefore, for every area of virtual memory in the process&#8217;s address space Linux needs to know where\nthat virtual memory comes from and how to get it into memory so that it can fix up these page\nfaults.\n<p>\n<img decoding=\"async\" src=\"process-vm.gif\">\n<p>\nFigure: A Process&#8217;s Virtual Memory\n<p>The Linux kernel needs to manage all of these areas of virtual memory and the contents\nof each process&#8217;s virtual memory is described by a <tt>mm_struct<\/tt> data structure\npointed at from its <tt>task_struct<\/tt>.\nThe process&#8217;s <tt>mm_struct<\/tt>\n<p>\ndata structure also contains information about the loaded\nexecutable image and a pointer to the process&#8217;s page tables.\nIt contains pointers to a list of <tt>vm_area_struct<\/tt> data structures, each\nrepresenting an area of virtual memory within this process.\n<p>\nThis linked list is in ascending virtual memory order, the figure above\nshows the layout in virtual memory of a simple process together with the kernel data structures\nmanaging it.\nAs those areas of virtual memory are from several sources, Linux abstracts the interface\nby having the <tt>vm_area_struct<\/tt> point to a set of virtual memory handling routines\n(via <tt>vm_ops<\/tt>).\nThis way all of the process&#8217;s virtual memory can be handled in a consistent\nway no matter how the underlying services managing that memory differ.\nFor example there is a routine that will be called when the process attempts to\naccess the memory and it does not exist, this is how page faults are handled.\n<p>\nThe process&#8217;s set of <tt>vm_area_struct<\/tt> data structures is accessed repeatedly\nby the Linux kernel as it creates new areas of virtual memory for the process and as it\nfixes up references to virtual memory not in the system&#8217;s physical memory.\nThis makes the time that it takes to find the correct <tt>vm_area_struct<\/tt> critical\nto the performance of the system.\nTo speed up this access, Linux also arranges the <tt>vm_area_struct<\/tt> data structures\ninto an AVL (Adelson-Velskii and Landis) tree.\nThis tree is arranged so that each <tt>vm_area_struct<\/tt> (or node) has a left and a right\npointer to its neighbouring <tt>vm_area_struct<\/tt> structure.\nThe left pointer points to node with a lower starting virtual address and the right\npointer points to a node with a higher starting virtual address.\nTo find the correct node, Linux goes to the root of the tree and follows each node&#8217;s\nleft and right pointers until it finds the right <tt>vm_area_struct<\/tt>.\nOf course, nothing is for free and inserting a new <tt>vm_area_struct<\/tt> into this tree\ntakes additional processing time.\n<p>\nWhen a process allocates virtual memory, Linux does not actually reserve physical memory\nfor the process.\nInstead, it describes the virtual memory by creating a new <tt>vm_area_struct<\/tt> data structure.\nThis is linked into the process&#8217;s list of virtual memory.\nWhen the process attempts to write to a virtual address within that new virtual\nmemory region then the system will page fault.\nThe processor will attempt to decode the virtual address, but as there are no\nPage Table Entries for any of this memory, it will give up and raise a page fault exception,\nleaving the Linux kernel to fix things up.\nLinux looks to see if the virtual address referenced is in the current process&#8217;s virtual\naddress space.\nIf it is, Linux creates the appropriate PTEs and allocates a physical page of memory\nfor this process.\nThe code or data may need to be brought into that physical page from the filesystem or\nfrom the swap disk.\nThe process can then be restarted at the instruction that caused the page fault and, this\ntime as the memory physically exists, it may continue.\n<p>\n<p>\nA process&#8217;s virtual memory contains executable code and data from many sources.\nFirst there is the program image that is loaded; for example a command like <font face=\"helvetica\">ls<\/font>.\nThis command, like all executable images, is composed of both executable code and data.\nThe image file contains all of the information neccessary to load the executable code and\nassociated program data into the virtual memory of the process.\nSecondly, processses can allocate (virtual) memory to use during their processing, say to\nhold the contents of files that it is reading.\nThis newly allocated, virtual, memory needs to be linked into the process&#8217;s existing virtual\nmemory so that it can be used.\nThirdly, Linux processes use libraries of commonly useful code, for example file handling\nroutines.\nIt does not make sense that each process has its own copy of the library, Linux uses\nshared libraries that can be used by several running processes at the same time.\nThe code and the data from these shared libraries must be linked into this process&#8217;s\nvirtual address space and also into the virtual address space of the other processes\nsharing the library.\n<p>\nIn any given time period a process will not have used all of the code and data contained\nwithin its virtual memory.\nIt could contain code that is only used during certain situations, such as during initialization\nor to process a particular event.\nIt may only have used some of the routines from its shared libraries.\nIt would be wasteful to load all of this code and data into physical memory where it would\nlie unused.\nMultiply this wastage by the number of processes in the system and the system would\nrun very inefficiently.\nInstead, Linux uses a technique called <em>demand paging<\/em> where the virtual memory of a process\nis brought into physical memory only when a process attempts to use it.\nSo, instead of loading the code and data into physical memory straight away, the Linux kernel\nalters the process&#8217;s page table, marking the virtual areas as existing but not in memory.\nWhen the process attempts to acccess the code or data the system hardware will generate\na page fault and hand control to the Linux kernel to fix things up.\nTherefore, for every area of virtual memory in the process&#8217;s address space Linux needs to know where\nthat virtual memory comes from and how to get it into memory so that it can fix up these page\nfaults.\n<p<img decoding=\"async\" src=\"process-vm.gif\"><br \/>\n<p>\nFigure: A Process&#8217;s Virtual Memory\n<p>\n<p>The Linux kernel needs to manage all of these areas of virtual memory and the contents\nof each process&#8217;s virtual memory is described by a <tt>mm_struct<\/tt> data structure\npointed at from its <tt>task_struct<\/tt>.\nThe process&#8217;s <tt>mm_struct<\/tt>\n<p>\ndata structure also contains information about the loaded\nexecutable image and a pointer to the process&#8217;s page tables.\nIt contains pointers to a list of <tt>vm_area_struct<\/tt> data structures, each\nrepresenting an area of virtual memory within this process.\n<p>\nThis linked list is in ascending virtual memory order, the figure above\nshows the layout in virtual memory of a simple process together with the kernel data structures\nmanaging it.\nAs those areas of virtual memory are from several sources, Linux abstracts the interface\nby having the <tt>vm_area_struct<\/tt> point to a set of virtual memory handling routines\n(via <tt>vm_ops<\/tt>).\nThis way all of the process&#8217;s virtual memory can be handled in a consistent\nway no matter how the underlying services managing that memory differ.\nFor example there is a routine that will be called when the process attempts to\naccess the memory and it does not exist, this is how page faults are handled.\n<p>\nThe process&#8217;s set of <tt>vm_area_struct<\/tt> data structures is accessed repeatedly\nby the Linux kernel as it creates new areas of virtual memory for the process and as it\nfixes up references to virtual memory not in the system&#8217;s physical memory.\nThis makes the time that it takes to find the correct <tt>vm_area_struct<\/tt> critical\nto the performance of the system.\nTo speed up this access, Linux also arranges the <tt>vm_area_struct<\/tt> data structures\ninto an AVL (Adelson-Velskii and Landis) tree.\nThis tree is arranged so that each <tt>vm_area_struct<\/tt> (or node) has a left and a right\npointer to its neighbouring <tt>vm_area_struct<\/tt> structure.\nThe left pointer points to node with a lower starting virtual address and the right\npointer points to a node with a higher starting virtual address.\nTo find the correct node, Linux goes to the root of the tree and follows each node&#8217;s\nleft and right pointers until it finds the right <tt>vm_area_struct<\/tt>.\nOf course, nothing is for free and inserting a new <tt>vm_area_struct<\/tt> into this tree\ntakes additional processing time.\n<p>\nWhen a process allocates virtual memory, Linux does not actually reserve physical memory\nfor the process.\nInstead, it describes the virtual memory by creating a new <tt>vm_area_struct<\/tt> data structure.\nThis is linked into the process&#8217;s list of virtual memory.\nWhen the process attempts to write to a virtual address within that new virtual\nmemory region then the system will page fault.\nThe processor will attempt to decode the virtual address, but as there are no\nPage Table Entries for any of this memory, it will give up and raise a page fault exception,\nleaving the Linux kernel to fix things up.\nLinux looks to see if the virtual address referenced is in the current process&#8217;s virtual\naddress space.\nIf it is, Linux creates the appropriate PTEs and allocates a physical page of memory\nfor this process.\nThe code or data may need to be brought into that physical page from the filesystem or\nfrom the swap disk.\nThe process can then be restarted at the instruction that caused the page fault and, this\ntime as the memory physically exists, it may continue.\n","protected":false},"excerpt":{"rendered":"<p>Virtual Memory A process&#8217;s virtual memory contains executable code and data from many sources. First there is the program image that is loaded; for example a command like ls. This command, like all executable images, is composed of both executable &hellip; <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=469\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-469","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/469","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=469"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/469\/revisions"}],"predecessor-version":[{"id":670,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/469\/revisions\/670"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=469"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}