Page tables allow the OS to multiplex process address spaces onto physical memory, protect memory between processes, and map kernel memory in user address spaces. Page tables are stored as a two-level tree structure with a page directory and page table pages. Virtual addresses are translated to physical addresses by indexing the page directory and table to obtain the physical page number in the page table entry.
A fast file system for unix presentation by parang saraf (cs5204 VT)Parang Saraf
This is the presentation of the paper "A fast file system for unix"
In case if you need a copy of these slides feel free to contact me at parang[DOT]saraf[AT]gmail
A fast file system for unix presentation by parang saraf (cs5204 VT)Parang Saraf
This is the presentation of the paper "A fast file system for unix"
In case if you need a copy of these slides feel free to contact me at parang[DOT]saraf[AT]gmail
The Linux Kernel Implementation of Pipes and FIFOsDivye Kapoor
A walkthrough of the code structure used in the linux kernel to implement pipes and FIFOs.
This was presented to a Senior level class at the Indian Institute of Technology, Roorkee.
This lecture describes the virtual filesystems procfs and sysfs.
Video for this Lecture on youtube:
http://www.youtube.com/watch?v=wlxL-iQN6No
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
OSDC 2011 | Enterprise Linux Server Filesystems by Remo RickliNETWAYS
Der Einsatz des richtigen Filesystems ist noch immer eine grundlegende Entscheidung mit großem Einfluss auf spätere Performance und Management. Mit Ext4 und BTRFS gibt es nun zwei neue Alternativen die der Erwartungshaltung bisherige Schwachstellen auszumerzen standhalten müssen. Während Ext4 bereits stable ist und den Sprung in die gängigen Enterprise Distributionen geschafft hat, steht das von Oracle BTRFS hier noch eher am Anfang. Trotz des scheinbaren Nachteils sehen vielen in BTRFS das nächste Standardfilesystem für Linux, da es im Vergleich bestehenden Limitierungen von Ext4 auflöst und als die Linux-Alternative zu ZFS gesehen wird.
Der Vortrag erläutert Architektur und Charakteristiken beider Dateisysteme, bewertet sie aus Sicht eines Systemadministrators für den Einsatz im Rechenzentrum und beschreibt mögliche Migrationspfade.
This lecture covers the handling of files and file management commands by Linux Subsystems. It also covers creating both Hard Links and Symbolic Links
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
- https://www.linkedin.com/in/ahmedelarabawy
Workshop - Linux Memory Analysis with VolatilityAndrew Case
Slides from my 3 hour workshop at Blackhat Vegas 2011. Covers using Volatility to perform Linux memory analysis investigations as well Linux kernel internals.
Course 102: Lecture 24: Archiving and Compression of Files Ahmed El-Arabawy
This lecture discusses the different commands and utilities used for archiving and compression of files and directories in Linux
Video for this lecture on youtube:
http://www.youtube.com/watch?v=R6ZQ6PJyy28
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
The Linux Kernel Implementation of Pipes and FIFOsDivye Kapoor
A walkthrough of the code structure used in the linux kernel to implement pipes and FIFOs.
This was presented to a Senior level class at the Indian Institute of Technology, Roorkee.
This lecture describes the virtual filesystems procfs and sysfs.
Video for this Lecture on youtube:
http://www.youtube.com/watch?v=wlxL-iQN6No
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
OSDC 2011 | Enterprise Linux Server Filesystems by Remo RickliNETWAYS
Der Einsatz des richtigen Filesystems ist noch immer eine grundlegende Entscheidung mit großem Einfluss auf spätere Performance und Management. Mit Ext4 und BTRFS gibt es nun zwei neue Alternativen die der Erwartungshaltung bisherige Schwachstellen auszumerzen standhalten müssen. Während Ext4 bereits stable ist und den Sprung in die gängigen Enterprise Distributionen geschafft hat, steht das von Oracle BTRFS hier noch eher am Anfang. Trotz des scheinbaren Nachteils sehen vielen in BTRFS das nächste Standardfilesystem für Linux, da es im Vergleich bestehenden Limitierungen von Ext4 auflöst und als die Linux-Alternative zu ZFS gesehen wird.
Der Vortrag erläutert Architektur und Charakteristiken beider Dateisysteme, bewertet sie aus Sicht eines Systemadministrators für den Einsatz im Rechenzentrum und beschreibt mögliche Migrationspfade.
This lecture covers the handling of files and file management commands by Linux Subsystems. It also covers creating both Hard Links and Symbolic Links
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
- https://www.linkedin.com/in/ahmedelarabawy
Workshop - Linux Memory Analysis with VolatilityAndrew Case
Slides from my 3 hour workshop at Blackhat Vegas 2011. Covers using Volatility to perform Linux memory analysis investigations as well Linux kernel internals.
Course 102: Lecture 24: Archiving and Compression of Files Ahmed El-Arabawy
This lecture discusses the different commands and utilities used for archiving and compression of files and directories in Linux
Video for this lecture on youtube:
http://www.youtube.com/watch?v=R6ZQ6PJyy28
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
The objectives of Memory Management strategies in Operating Systems are:
- To provide a detailed description of various ways of organizing memory hardware
- To discuss various memory-management techniques, including paging and segmentation
- To provide a detailed description of the Intel Pentium, which supports both pure segmentation and segmentation with paging
Linux Kernel Booting Process (2) - For NLKBshimosawa
Describes the bootstrapping part in Linux, and related architectural mechanisms and technologies.
This is the part two of the slides, and the succeeding slides may contain the errata for this slide.
The objectives of these slides are:
- To provide a detailed description of various ways of organizing memory hardware
- To discuss various memory-management techniques, including paging and segmentation
- To provide a detailed description of the Intel Pentium, which supports both pure segmentation and segmentation with paging
In this presentation I talk about various topics related to Memory Management in SQL Server such as:
1. Memory Manager: Windows NT
a. Virtual memory
i. Address Space Layout
ii. Virtual Memory Manager
iii. 32-bit Virtual Addresses
iv. Address Translation
b. Memory Pool
c. 4GT Tuning
i. /3GB Switch (Two slides)
ii. Effects of /3GB Tuning
iii. /USERVA Switch
d. PAE
i. Using /3GB & PAE together
e. AWE
f. 32-bit vs 64-bit Virtual Memory
2. Memory Manager: SQLOS
a. SQLOS
i. Memory Management
ii. Scheduling
iii. Exception handling
b. NUMA (Non-Uniform Memory Architecture)
c. BP and MTL ?
d. Memory Types
e. Memory Pressure
Physical address space of a process can be noncontiguous; process is allocated physical memory whenever the latter is available
Avoids external fragmentation
Avoids problem of varying sized memory chunks
Divide physical memory into fixed-sized blocks called frames
Size is power of 2, between 512 bytes and 16 Mbytes
Divide logical memory into blocks of same size called pages
Keep track of all free frames
To run a program of size N pages, need to find N free frames and load program
Set up a page table to translate logical to physical addresses
Backing store likewise split into pages
Still have Internal fragmentation
The Metaverse and AI: how can decision-makers harness the Metaverse for their...Jen Stirrup
The Metaverse is popularized in science fiction, and now it is becoming closer to being a part of our daily lives through the use of social media and shopping companies. How can businesses survive in a world where Artificial Intelligence is becoming the present as well as the future of technology, and how does the Metaverse fit into business strategy when futurist ideas are developing into reality at accelerated rates? How do we do this when our data isn't up to scratch? How can we move towards success with our data so we are set up for the Metaverse when it arrives?
How can you help your company evolve, adapt, and succeed using Artificial Intelligence and the Metaverse to stay ahead of the competition? What are the potential issues, complications, and benefits that these technologies could bring to us and our organizations? In this session, Jen Stirrup will explain how to start thinking about these technologies as an organisation.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Enhancing Performance with Globus and the Science DMZGlobus
ESnet has led the way in helping national facilities—and many other institutions in the research community—configure Science DMZs and troubleshoot network issues to maximize data transfer performance. In this talk we will present a summary of approaches and tips for getting the most out of your network infrastructure using Globus Connect Server.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Welcome to the first live UiPath Community Day Dubai! Join us for this unique occasion to meet our local and global UiPath Community and leaders. You will get a full view of the MEA region's automation landscape and the AI Powered automation technology capabilities of UiPath. Also, hosted by our local partners Marc Ellis, you will enjoy a half-day packed with industry insights and automation peers networking.
📕 Curious on our agenda? Wait no more!
10:00 Welcome note - UiPath Community in Dubai
Lovely Sinha, UiPath Community Chapter Leader, UiPath MVPx3, Hyper-automation Consultant, First Abu Dhabi Bank
10:20 A UiPath cross-region MEA overview
Ashraf El Zarka, VP and Managing Director MEA, UiPath
10:35: Customer Success Journey
Deepthi Deepak, Head of Intelligent Automation CoE, First Abu Dhabi Bank
11:15 The UiPath approach to GenAI with our three principles: improve accuracy, supercharge productivity, and automate more
Boris Krumrey, Global VP, Automation Innovation, UiPath
12:15 To discover how Marc Ellis leverages tech-driven solutions in recruitment and managed services.
Brendan Lingam, Director of Sales and Business Development, Marc Ellis
1. Lab 7: Page tables
Advanced Operating Systems
Zubair Nabi
zubair.nabi@itu.edu.pk
March 27, 2013
2. Introduction
Page tables allow the OS to:
• Multiplex the address spaces of different processes onto a single
physical memory space
• Protect the memories of different processes
• Map the same kernel memory in several address spaces
• Map the same user memory more than once in one address
space (user pages are also mapped into the kernel’s physical
view of memory)
3. Introduction
Page tables allow the OS to:
• Multiplex the address spaces of different processes onto a single
physical memory space
• Protect the memories of different processes
• Map the same kernel memory in several address spaces
• Map the same user memory more than once in one address
space (user pages are also mapped into the kernel’s physical
view of memory)
4. Introduction
Page tables allow the OS to:
• Multiplex the address spaces of different processes onto a single
physical memory space
• Protect the memories of different processes
• Map the same kernel memory in several address spaces
• Map the same user memory more than once in one address
space (user pages are also mapped into the kernel’s physical
view of memory)
5. Introduction
Page tables allow the OS to:
• Multiplex the address spaces of different processes onto a single
physical memory space
• Protect the memories of different processes
• Map the same kernel memory in several address spaces
• Map the same user memory more than once in one address
space (user pages are also mapped into the kernel’s physical
view of memory)
6. Introduction
Page tables allow the OS to:
• Multiplex the address spaces of different processes onto a single
physical memory space
• Protect the memories of different processes
• Map the same kernel memory in several address spaces
• Map the same user memory more than once in one address
space (user pages are also mapped into the kernel’s physical
view of memory)
7. Page table structure
• An x86 page table contains 220 page table entries (PTEs)
• Each PTE contains a 20-bit physical page number (PPN) and
some flags
• The paging hardware translates virtual addresses to physical
ones by:
Using the top 20 bits of the virtual address to index into the page
table to find a PTE
2 Replacing the top 20 bits with the PPN in the PTE
3 Copying the lower 12 bits verbatim from the virtual to the physical
address
1
• Translation takes place at the granularity of 212 byte (4KB)
chunks, called pages
8. Page table structure
• An x86 page table contains 220 page table entries (PTEs)
• Each PTE contains a 20-bit physical page number (PPN) and
some flags
• The paging hardware translates virtual addresses to physical
ones by:
Using the top 20 bits of the virtual address to index into the page
table to find a PTE
2 Replacing the top 20 bits with the PPN in the PTE
3 Copying the lower 12 bits verbatim from the virtual to the physical
address
1
• Translation takes place at the granularity of 212 byte (4KB)
chunks, called pages
9. Page table structure
• An x86 page table contains 220 page table entries (PTEs)
• Each PTE contains a 20-bit physical page number (PPN) and
some flags
• The paging hardware translates virtual addresses to physical
ones by:
Using the top 20 bits of the virtual address to index into the page
table to find a PTE
2 Replacing the top 20 bits with the PPN in the PTE
3 Copying the lower 12 bits verbatim from the virtual to the physical
address
1
• Translation takes place at the granularity of 212 byte (4KB)
chunks, called pages
10. Page table structure
• An x86 page table contains 220 page table entries (PTEs)
• Each PTE contains a 20-bit physical page number (PPN) and
some flags
• The paging hardware translates virtual addresses to physical
ones by:
Using the top 20 bits of the virtual address to index into the page
table to find a PTE
2 Replacing the top 20 bits with the PPN in the PTE
3 Copying the lower 12 bits verbatim from the virtual to the physical
address
1
• Translation takes place at the granularity of 212 byte (4KB)
chunks, called pages
11. Page table structure
• An x86 page table contains 220 page table entries (PTEs)
• Each PTE contains a 20-bit physical page number (PPN) and
some flags
• The paging hardware translates virtual addresses to physical
ones by:
Using the top 20 bits of the virtual address to index into the page
table to find a PTE
2 Replacing the top 20 bits with the PPN in the PTE
3 Copying the lower 12 bits verbatim from the virtual to the physical
address
1
• Translation takes place at the granularity of 212 byte (4KB)
chunks, called pages
12. Page table structure
• An x86 page table contains 220 page table entries (PTEs)
• Each PTE contains a 20-bit physical page number (PPN) and
some flags
• The paging hardware translates virtual addresses to physical
ones by:
Using the top 20 bits of the virtual address to index into the page
table to find a PTE
2 Replacing the top 20 bits with the PPN in the PTE
3 Copying the lower 12 bits verbatim from the virtual to the physical
address
1
• Translation takes place at the granularity of 212 byte (4KB)
chunks, called pages
13. Page table structure
• An x86 page table contains 220 page table entries (PTEs)
• Each PTE contains a 20-bit physical page number (PPN) and
some flags
• The paging hardware translates virtual addresses to physical
ones by:
Using the top 20 bits of the virtual address to index into the page
table to find a PTE
2 Replacing the top 20 bits with the PPN in the PTE
3 Copying the lower 12 bits verbatim from the virtual to the physical
address
1
• Translation takes place at the granularity of 212 byte (4KB)
chunks, called pages
14. Page table structure (2)
• A page table is stored in physical memory as a two-level tree
• Root of the tree: 4KB page directory
• Each page directory index: page table pages (PDE)
• Each page table page: 1024 32-bit PTEs
• 1024 x 1024 = 220
15. Page table structure (2)
• A page table is stored in physical memory as a two-level tree
• Root of the tree: 4KB page directory
• Each page directory index: page table pages (PDE)
• Each page table page: 1024 32-bit PTEs
• 1024 x 1024 = 220
16. Page table structure (2)
• A page table is stored in physical memory as a two-level tree
• Root of the tree: 4KB page directory
• Each page directory index: page table pages (PDE)
• Each page table page: 1024 32-bit PTEs
• 1024 x 1024 = 220
17. Page table structure (2)
• A page table is stored in physical memory as a two-level tree
• Root of the tree: 4KB page directory
• Each page directory index: page table pages (PDE)
• Each page table page: 1024 32-bit PTEs
• 1024 x 1024 = 220
18. Page table structure (2)
• A page table is stored in physical memory as a two-level tree
• Root of the tree: 4KB page directory
• Each page directory index: page table pages (PDE)
• Each page table page: 1024 32-bit PTEs
• 1024 x 1024 = 220
19. Translation
• Use top 10 bits of the virtual address to index the page directory
• If the PDE is present, use next 10 bits to index the page table
page and obtain a PTE
• If either the PDE or the PTE is missing, raise a fault
• This two-level structure increases efficiency
• How?
20. Translation
• Use top 10 bits of the virtual address to index the page directory
• If the PDE is present, use next 10 bits to index the page table
page and obtain a PTE
• If either the PDE or the PTE is missing, raise a fault
• This two-level structure increases efficiency
• How?
21. Translation
• Use top 10 bits of the virtual address to index the page directory
• If the PDE is present, use next 10 bits to index the page table
page and obtain a PTE
• If either the PDE or the PTE is missing, raise a fault
• This two-level structure increases efficiency
• How?
22. Translation
• Use top 10 bits of the virtual address to index the page directory
• If the PDE is present, use next 10 bits to index the page table
page and obtain a PTE
• If either the PDE or the PTE is missing, raise a fault
• This two-level structure increases efficiency
• How?
23. Permissions
Each PTE contains associated flags
Flag
PTE_P
PTE_W
PTE_U
PTE_PWT
PTE_PCD
PTE_A
PTE_D
PTE_PS
Description
Whether the page is present
Whether the page can be written to
Whether user programs can access the page
Whether write through or write back
Whether caching is disabled
Whether the page has been accessed
Whether the page is dirty
Page size
24. Process address space
• Each process has a private address space which is switched on a
context switch (via switchuvm)
• Each address space starts at 0 and goes up to KERNBASE
allowing 2GB of space (specific to xv6)
• Each time a process requests more memory, the kernel:
Finds free physical pages
Adds PTEs that point to these physical pages in the process’ page
table
3 Sets PTE_U, PTE_W, and PTE_P
1
2
25. Process address space
• Each process has a private address space which is switched on a
context switch (via switchuvm)
• Each address space starts at 0 and goes up to KERNBASE
allowing 2GB of space (specific to xv6)
• Each time a process requests more memory, the kernel:
Finds free physical pages
Adds PTEs that point to these physical pages in the process’ page
table
3 Sets PTE_U, PTE_W, and PTE_P
1
2
26. Process address space
• Each process has a private address space which is switched on a
context switch (via switchuvm)
• Each address space starts at 0 and goes up to KERNBASE
allowing 2GB of space (specific to xv6)
• Each time a process requests more memory, the kernel:
Finds free physical pages
Adds PTEs that point to these physical pages in the process’ page
table
3 Sets PTE_U, PTE_W, and PTE_P
1
2
27. Process address space
• Each process has a private address space which is switched on a
context switch (via switchuvm)
• Each address space starts at 0 and goes up to KERNBASE
allowing 2GB of space (specific to xv6)
• Each time a process requests more memory, the kernel:
Finds free physical pages
Adds PTEs that point to these physical pages in the process’ page
table
3 Sets PTE_U, PTE_W, and PTE_P
1
2
28. Process address space
• Each process has a private address space which is switched on a
context switch (via switchuvm)
• Each address space starts at 0 and goes up to KERNBASE
allowing 2GB of space (specific to xv6)
• Each time a process requests more memory, the kernel:
Finds free physical pages
Adds PTEs that point to these physical pages in the process’ page
table
3 Sets PTE_U, PTE_W, and PTE_P
1
2
29. Process address space
• Each process has a private address space which is switched on a
context switch (via switchuvm)
• Each address space starts at 0 and goes up to KERNBASE
allowing 2GB of space (specific to xv6)
• Each time a process requests more memory, the kernel:
Finds free physical pages
Adds PTEs that point to these physical pages in the process’ page
table
3 Sets PTE_U, PTE_W, and PTE_P
1
2
30. Process address space (2)
Each process’ address space also contains mappings (above
KERNBASE) for the kernel to run. Specifically:
• KERNBASE:KERNBASE+PHYSTOP is mapped to 0:PHYSTOP
• The kernel can use its own instructions and data
• The kernel can directly write to physical memory (for instance,
when creating page table pages)
• A shortcoming of this approach is that the kernel can only make
use of 2GB of memory
• PTE_U is not set for all entries above KERNBASE
31. Process address space (2)
Each process’ address space also contains mappings (above
KERNBASE) for the kernel to run. Specifically:
• KERNBASE:KERNBASE+PHYSTOP is mapped to 0:PHYSTOP
• The kernel can use its own instructions and data
• The kernel can directly write to physical memory (for instance,
when creating page table pages)
• A shortcoming of this approach is that the kernel can only make
use of 2GB of memory
• PTE_U is not set for all entries above KERNBASE
32. Process address space (2)
Each process’ address space also contains mappings (above
KERNBASE) for the kernel to run. Specifically:
• KERNBASE:KERNBASE+PHYSTOP is mapped to 0:PHYSTOP
• The kernel can use its own instructions and data
• The kernel can directly write to physical memory (for instance,
when creating page table pages)
• A shortcoming of this approach is that the kernel can only make
use of 2GB of memory
• PTE_U is not set for all entries above KERNBASE
33. Process address space (2)
Each process’ address space also contains mappings (above
KERNBASE) for the kernel to run. Specifically:
• KERNBASE:KERNBASE+PHYSTOP is mapped to 0:PHYSTOP
• The kernel can use its own instructions and data
• The kernel can directly write to physical memory (for instance,
when creating page table pages)
• A shortcoming of this approach is that the kernel can only make
use of 2GB of memory
• PTE_U is not set for all entries above KERNBASE
34. Process address space (2)
Each process’ address space also contains mappings (above
KERNBASE) for the kernel to run. Specifically:
• KERNBASE:KERNBASE+PHYSTOP is mapped to 0:PHYSTOP
• The kernel can use its own instructions and data
• The kernel can directly write to physical memory (for instance,
when creating page table pages)
• A shortcoming of this approach is that the kernel can only make
use of 2GB of memory
• PTE_U is not set for all entries above KERNBASE
35. Process address space (2)
Each process’ address space also contains mappings (above
KERNBASE) for the kernel to run. Specifically:
• KERNBASE:KERNBASE+PHYSTOP is mapped to 0:PHYSTOP
• The kernel can use its own instructions and data
• The kernel can directly write to physical memory (for instance,
when creating page table pages)
• A shortcoming of this approach is that the kernel can only make
use of 2GB of memory
• PTE_U is not set for all entries above KERNBASE
36. Example: Creating an address space for main
• main makes a call to kvmalloc
• kvmalloc creates a page table with kernel mappings above
KERNBASE and switches to it
1
2
3
4
5
void kvmalloc (void)
{
kpgdir = setupkvm ();
switchkvm ();
}
37. Example: Creating an address space for main
• main makes a call to kvmalloc
• kvmalloc creates a page table with kernel mappings above
KERNBASE and switches to it
1
2
3
4
5
void kvmalloc (void)
{
kpgdir = setupkvm ();
switchkvm ();
}
38. Example: Creating an address space for main
• main makes a call to kvmalloc
• kvmalloc creates a page table with kernel mappings above
KERNBASE and switches to it
1
2
3
4
5
void kvmalloc (void)
{
kpgdir = setupkvm ();
switchkvm ();
}
39. setupkvm
1
Allocates a page of memory to hold the page directory
2
Calls mappages to install kernel mappings (kmap)
• Instructions and data
• Physical memory up to PHYSTOP
• Memory ranges for I/O devices
Does not install mappings for user memory
40. setupkvm
1
Allocates a page of memory to hold the page directory
2
Calls mappages to install kernel mappings (kmap)
• Instructions and data
• Physical memory up to PHYSTOP
• Memory ranges for I/O devices
Does not install mappings for user memory
41. setupkvm
1
Allocates a page of memory to hold the page directory
2
Calls mappages to install kernel mappings (kmap)
• Instructions and data
• Physical memory up to PHYSTOP
• Memory ranges for I/O devices
Does not install mappings for user memory
42. setupkvm
1
Allocates a page of memory to hold the page directory
2
Calls mappages to install kernel mappings (kmap)
• Instructions and data
• Physical memory up to PHYSTOP
• Memory ranges for I/O devices
Does not install mappings for user memory
43. setupkvm
1
Allocates a page of memory to hold the page directory
2
Calls mappages to install kernel mappings (kmap)
• Instructions and data
• Physical memory up to PHYSTOP
• Memory ranges for I/O devices
Does not install mappings for user memory
44. setupkvm
1
Allocates a page of memory to hold the page directory
2
Calls mappages to install kernel mappings (kmap)
• Instructions and data
• Physical memory up to PHYSTOP
• Memory ranges for I/O devices
Does not install mappings for user memory
47. mappages
• Installs virtual to physical mappings for a range of addresses
• For each virtual address:
1 Calls walkpgdir to find address of the PTE for that address
2
Initializes the PTE with the relevant PPN and the desired
permissions
48. mappages
• Installs virtual to physical mappings for a range of addresses
• For each virtual address:
1 Calls walkpgdir to find address of the PTE for that address
2
Initializes the PTE with the relevant PPN and the desired
permissions
49. mappages
• Installs virtual to physical mappings for a range of addresses
• For each virtual address:
1 Calls walkpgdir to find address of the PTE for that address
2
Initializes the PTE with the relevant PPN and the desired
permissions
50. mappages
• Installs virtual to physical mappings for a range of addresses
• For each virtual address:
1 Calls walkpgdir to find address of the PTE for that address
2
Initializes the PTE with the relevant PPN and the desired
permissions
51. walkpgdir
1
Uses the upper 10 bits of the virtual address to find the PDE
2
Uses the next 10 bits to find the PTE
52. walkpgdir
1
Uses the upper 10 bits of the virtual address to find the PDE
2
Uses the next 10 bits to find the PTE
53. Physical memory allocation
• Physical memory between the end of the kernel and PHYSTOP is
allocated on the fly
• Free pages are maintained through a linked list struct run
*freelist protected by a spinlock
1 Allocation: Remove a page from the list: kalloc()
2 Deallocation: Add the page to the list: kfree()
1
2
3
4
5
struct {
struct spinlock lock;
int use_lock ;
struct run
} kmem;
∗freelist ;
54. Physical memory allocation
• Physical memory between the end of the kernel and PHYSTOP is
allocated on the fly
• Free pages are maintained through a linked list struct run
*freelist protected by a spinlock
1 Allocation: Remove a page from the list: kalloc()
2 Deallocation: Add the page to the list: kfree()
1
2
3
4
5
struct {
struct spinlock lock;
int use_lock ;
struct run
} kmem;
∗freelist ;
55. Physical memory allocation
• Physical memory between the end of the kernel and PHYSTOP is
allocated on the fly
• Free pages are maintained through a linked list struct run
*freelist protected by a spinlock
1 Allocation: Remove a page from the list: kalloc()
2 Deallocation: Add the page to the list: kfree()
1
2
3
4
5
struct {
struct spinlock lock;
int use_lock ;
struct run
} kmem;
∗freelist ;
56. Physical memory allocation
• Physical memory between the end of the kernel and PHYSTOP is
allocated on the fly
• Free pages are maintained through a linked list struct run
*freelist protected by a spinlock
1 Allocation: Remove a page from the list: kalloc()
2 Deallocation: Add the page to the list: kfree()
1
2
3
4
5
struct {
struct spinlock lock;
int use_lock ;
struct run
} kmem;
∗freelist ;
57. Physical memory allocation
• Physical memory between the end of the kernel and PHYSTOP is
allocated on the fly
• Free pages are maintained through a linked list struct run
*freelist protected by a spinlock
1 Allocation: Remove a page from the list: kalloc()
2 Deallocation: Add the page to the list: kfree()
1
2
3
4
5
struct {
struct spinlock lock;
int use_lock ;
struct run
} kmem;
∗freelist ;
58. exec
• Creates the user part of an address space from the program
binary, in Executable and Linkable Format (ELF)
• Initializes instructions, data, and stack
59. exec
• Creates the user part of an address space from the program
binary, in Executable and Linkable Format (ELF)
• Initializes instructions, data, and stack
60. Today’s task
• Most operating systems implement “anticipatory paging” in which
on a page fault, the next few consecutive pages are also loaded
to preemptively reduce page faults
• Chalk out a design to implement this strategy in xv6
61. Reading(s)
• Chapter 2, “Page tables” from “xv6: a simple, Unix-like teaching
operating system”