 Welcome we got a lot of materials so we're going to blaze through this hold on it's going to be quick So my name is Matt Porter. I'm with Consulco group and If you're looking for Alan, I'll explain on the next slide why I'm not he and you can probably tell because if you know Alan He's got hair down to here. So This is a introduction to memory management and I stress introduction So if you're experienced Colonel person, you might not get as much out of it This is the this is the presentation that back when when the early adopters Embedded litics back in 2000 2001. We're coming in from working on our tosses I wish I had sat down and put something this this good together because these are the things that everybody Needed to understand to really grasp their system alright, so Real quick about the original author Alan Ott. He couldn't be here. Unfortunately. Good friend of mine and he's a veteran at embedded Linux developer He's a Linux architect at Softiron You may have heard they're an arm server company, but he put together all this material. He's a fellow instructor LF training instructor also gives the the Colonel internals class that Contains a lot more than this material so he did a really nice job on the slide deck and Trusted me to present it as well. So Anyway, just want to give him the kudos for this awesome material. So here we go We're gonna talk about Memory management from beginning in the end and it's gonna be the intro as I said so we start at physical memory if you look at your Low-end systems. I have a single address space and memory and peripherals are sharing that same space they're mapped into different parts of that single address space and The all the processes in OS In in this type of system share the same memory space. There's no memory protection Like we you would often hear about and we're gonna get in all the details of this And you're running a process in that single address space Processes can stomp on each other because they're all shared in there. You have to separate them manually and quote user space or your user application can stomp on say your real-time executive that you're using the schedule So examples of these would be an 8086 Cortex-M part AVR's all these low-end microcontrollers in the old pre-MMU processors So let's take a look So it gives us I know a lot of us are not working on on x86 But it serves as a ubiquitous example if we look at a 32-bit x86 system right Lots of legacy obviously, but it is a common ground We have all of these legacy areas and so forth You have hardware mapped between RAM areas You can see that your PCI physical PCI area memory mapped IO is all in the high part. Okay, so that gives you an idea Physically what x86 looks like now What's the limitation with the single address space, right? You have portable C programs expect that they kind of own the whole thing, right? They don't they don't know if you're you're trying to port several C programs into one space You've got to go set the addresses of this this can live here and this can live in this segment So they don't stomp each other so it's kind of hard to do that You've got to have special knowledge of your actual platform Need to know what your total RAM is And you need as I'm saying you need to separate those processes You have to do all this work and there's no protection right as we said rogue programs can stomp all over things so incomes virtual memory and this is where Things get fun So what is it? Right? This it's a mapping. It's a virtual mapping hence the name virtual so So you map a virtual address a fake address to that? Physical address all right when we look back at that x86 Map that's all physical world and if we can just think in virtual addresses We can have any mapping we want so we map virtual addresses to physical RAM But we also map virtual addresses to hardware devices, right? So PCI GPU RAM on SOC IP blocks, right everything So what's the advantage right? Described how in that flat memory model the single address space we have a situation where you know I got to tell something to run at this address and this address and this address up the end times and Actually have a nice memory map of where everything lives. It's not portable, right? So When we have virtual memory, right? You have one processes RAM is inaccessible to the other processor it's also invisible right so you have built-in memory protection and Colonel RAM is not visible to user space directly The nice thing you have is that memory can be moved right so Memory can be visible to different processes, but you have to actually Set up a mapping for that and the other nice thing is rather than in a single address space Where you have all the memory? Sitting there and you have to manually share it and segment it All right, you can now do things like swapping memory out to disk because the addresses you're dealing with are just virtual The other thing you can do with virtual memory is map that hardware, right? We talked about can be mapped into your process address space Okay, we need help from a kernel to do that on behalf of of user space All right, the other thing is we can take RAM memory and we can map it into multiple processes All right, we're gonna get into that more and that's the the shared That would be a case where like a shared library, right where you're mapping it in the multiple processes And finally with virtual memory we get the ability to have rewrite execute permissions placed on those address accesses All right, so we have two address spaces now, right? We've got the physical addresses we talked about and we saw that physical memory map x86. We use an example and That's you know DMA peripherals whatever it maps out to in your physical world, right? Virtual addresses, right? And those are the ones that our actual software uses, right? When we get to our machine code, whatever whatever architecture, that's our load store accesses, right? Out to memory and those are always using virtual addresses all right, so Looking at virtual memory, right? We have to do a mapping this mapping is done in hardware So there's a piece of hardware that assists with these mappings. Okay, once we have it mapped. There's no penalty for Accessing memory that way, right? The permissions are handled without a penalty So this is all handled in hardware for us and we're going to talk about what that hardware is that does this And of course we use the same CPU instructions of same load stores whether it's RAM or a Piece of peripheral IO, okay? So in normal operation, you're always using virtual addresses all right, so what magic does this it's the memory management unit, right and So an MMU sits between the CPU core and the memory all right. It's often in a modern architecture part of the physical CPU itself if you look and Like retro things you'll find that MMUs were used to be a separate discrete part, right? And we're interfaced and we're part of that set Sold just like say a PMIC as often a an integral separate discrete piece of a architecture so The one thing to keep in mind is that the RAM controller is a separate piece So you got an MMU the DDR controller is going to be a separate IP block tightly coupled though And what does an MMU do right and what it does is it just does that magic of transparently handling of the translation of those load store Instructions into physical addresses, okay, so we map the memory accesses the virtual Addresses to our system RAM that physical address space we talked about right same thing with peripheral hardware No different from its point of view right it handles permissions. He said we got permissions with virtual memory and If we have an invalid access to something it's going to generate an exception and with that exception We can go do some interesting things We'll talk about that in a bit, okay How an MMU works there's an important piece of the MMU called the TLB translation look aside buffer, okay, and so that's just a hardware buffer that has a set of mappings and Those are your virtual to physical mappings. It'll have permissions for that space, okay, and There's a there's a granularity in which these mappings are kept and we're going to talk about that in a moment and The the interesting thing is that you know TLB design is a very architecture specific very part-specific performance sensitive and so you'll see a wide variance in how TLB is are designed how Mappings are placed in if it's software done or it's hardware assisted That type of thing and also Capabilities how many slots they have All right, so this is a quick little diagram of what a system looks like if you're having trouble Visualizing it where it sits you see the MMU between the memory controller, right and the CPU You see that TLB on the side with some entries, okay? All right, so they're saying with that TLB the MMU takes a look at that buffer, right? Is there already a mapping in there when it accesses a virtual address and Then it can look that up and if it doesn't Doesn't find one then it's going to generate the page fault Interrupt the CPU. Okay. Now if the address is in the TLB But you let's say you're doing a write access, but it's only set for read permission it's also going to generate an exception and That'll come back into play as we get into how we use those things in Linux so in Linux a page fault right so you have a CPU exception generated, okay, and This happens when you access that invalid virtual address what makes it invalid, right? It's not in the TLB, okay? and you have three cases, so First virtual address just isn't mapped. Okay for the process that's requesting it second, you don't have the right permissions, right and third would be that it's a valid virtual address, but it's currently swapped out And that one's a software condition So let's dive into we're gonna dive into each of those but first we're gonna get into kernel virtual memory side of things okay So we use virtual addresses both in the kernel and user space But the way that we use them how things are mapped are quite a bit different. So in the kernel we use them obviously and but we have this split in how we treat our virtual addresses and the upper part of our of our Virtual memory map is for the kernel in the lower part for user space and usually when we teach people about this it's harder to think with 64-bit addresses, so we go back to 32-bit and We affectionately call the default spot that it splits between user space and kernel spaces C bazillion That's at that 3 gig location. That is a default So this is what it looks like. So you saw that hugely complex physical memory map of x86 32-bit architecture and lo and behold, here's the virtual memory map We've got 3 gig for user space, right Config page offset controls where that split is set at, right? And so every process gets its own 3 gigabytes in that system It has that whole view so you remember to go back to that single address space If you had multiple processes you had to go link them and all these different spots and manage your processes very manually in this world When we link applications, they all end up at the same place, right? And the kernel just has this one gig in our 32-bit case Okay, so as we said that config page offset controls that a lot of architectures If you have specific needs you might fiddle with that a bit that sometimes happens in embedded stuff and the On 64-bit, we don't have this situation where there's ever a possible need to do that essentially On arm 64. We're at eight bazillion there x86 64 the splits at a different location But you know given RAM sizes and so forth It's effectively something that's that's not worried about in the 32-bit system where that page offset is is Has an effect on how we deal with large memory systems, which we'll talk about in a moment So there's three kinds of virtual addresses in Linux and and LDD defines these these best you can you can look at that and The way the way we define them are And some people use some different terminology historically But in the kernel side we have kernel logical addresses kernel kernel virtual addresses And then we have those user space virtual addresses, okay? There's another special case But most people don't speak about them exactly that way either physical or bus addresses But you can look at LDD 3 the link was in there for a little bit more information. So kernel logical addresses That's the what people consider the normal address space that they're normally dealing with what you get back from K malik is a Kernel logical address, okay, they have a fixed Offset, okay, and so You see a magic number there. That's the config page offset value And that would map to that now that that physical addresses specific to one architecture That could be wherever your base of RAM is and it does get more complicated in in various other Segmented memory systems, but this is an introduction. So we keep it simple So because this is a very simple mapping Logical mapping the conversion is really easy to do so visually it looks like this your kernel logical addresses are at page offset Point down assuming your physical RAM in that physical memory map is starts at zero boom you've got this very simple logical thing and Accordingly you have a very simple set of macros that can convert when it when it's a kernel linear or logical address okay now The next thing that it's interesting when when we have a small memory system, right? So we'll we'll call them small or large and this is really Specific to our 32-bit example, okay? So less than a gig of RAM. It's technically less than that really when when you look at where the splits at You have those kernel logical addresses right starting at the page offset and then going through the end of memory So if you had 512 megabyte, okay, then You would have C up through D all foxes right would be that kernel logical area So it's very simple when you have that small amount of memory. That's where it gets mapped into kernel logical space Okay So things that it includes in logical space like we already said Allocations with K malik Get free pages all of the all of those allocators and kernel stacks and The key thing here is And we haven't talked about how swapping works yet, but logical memory can never be swapped out. Okay There is As we said, there's that fixed mapping we saw how simple the Mac the macros were for that Okay, but what's because of that all everything in that kernel logical area? It's all physically contiguous. So that's important because we need that for DMA. So that's that's why you'll see K malik and those those types of allocations used with DMA will buffers, okay Okay, then it gets complicated if you're on a large memory system something more than a gig of RAM nominally Right, we run out of space right our page offset was at sea visit How are we gonna map that all into? Kernel we can't okay So there is We run out of room there and then on top of it we have to have the space for use by V malik Memory which is our kernel virtual address range and we need to keep that so we're gonna talk about that in a moment, okay? Once we go above that gig of RAM nominally, it's actually less then we have stuff Mapped into the kernel virtual Memory area, and so that's the the high mem support Again note that when we're taking the 32-bit model we have that problem with 64 bit We don't really effectively have that problem until we're gonna get ginormous amounts of RAM on the system Doesn't seem like it's gonna happen tomorrow in that space. Okay? All right, so Kernel logical Mapping right we saw a page offset and then in this large mem system, right? We don't have enough room for that so the additional RAM is going to be Mapped separately in that kernel virtual area So you don't have that logical mapping so those things you can't you can't use any of those simple macros on them at all Okay, so how do we call that? low memory is that Directly mapped set right and then the high memory there is Is you know not physically contiguous it gets mapped in on demand we only have that situation on 32-bit and The the key thing on the low memory as you saw and you can see it visually you go back to the these These sections that you have that one-to-one mapping there right, but the rest of it you do not Okay So let's talk a little bit more about kernel virtual addresses So the easy part was that logical set very simple right so kernel virtual addresses I usually call it V malik space like a lot of people and so keep in mind of that and That's that area above that logical range of its managed dynamically and So those are used for non contiguous mappings. So what's the practical case for that? Insmod right load a module Memories allocated it needs to be virtually contiguous for that module But doesn't need to be physically contiguous right so what you'll find is the module does V malik it's got that virtually contiguous area and But the actual physical backing RAM could be scattered anywhere Okay The other piece is memory mapped IO you're using IO remap and friends will get into that right and That also ends up in that space so All right, so quick look at that. We've got logical addresses physical RAM Whoo Yeah, and so that that's what that looks like and then you've got your virtual address space up there right your modules are getting installed your IO remaps all of that all right So keep in mind as we said that the key there is it's non contiguous right you can't can't Can't rely on it for DMA at all. That's the main point here that Yeah, so this is this is reiterating probably maybe too much is This emphasis that on the 32-bit machine, right? We have a very constrained space in that in the the the logical address space if we have You know 768 mega RAM. Okay, so there's less space for for kernel virtual addresses. So Those are tunable and you just don't deal with this problem on the 64-bit system All right, so let's jump into the meat of user virtual addresses because this is where it gets more complicated So our user virtual addresses, right? That's what our applications or our processes are our mapped into Okay, they're all below page offset if you remember that memory map we saw below the 3 gig mark in our modeled 32-bit system right and each process has its own mapping What I mean by mapping is its own view of virtual address space, right a thread shares mappings and Things get a little bit more complicated with the clone because there's a lot of options and you can choose how much you're sharing and so forth but that's beyond intro level and So one of the key things is Colonel virtual logical addresses, right? They have that fixed mapping. Okay user processes are fully used in the MMU and the only time the only time that you actually use RAM is when when When you're actually touching it will get into that right the memory isn't contiguous It's a lot like that V malik space and kernel you can't rely on anything being contiguous just because it looks that way from the virtual address, right and The nice thing is you can swap out remember kernel logical Virtual addresses, it's not swappable memory and the memory can be moved around on you. So That's virtual world All right, so What what does this fundamentally mean since things can be moved around on you it can be swapped out You can't use it for DMA right can't can't allocate can't malik memory And then try to DMA to that virtual address All right, it's not not going to be a stable backing behind it All right, how does this work every process has its own memory map? You can go look at struct MM right, there's pointers to that in your task struct for your process and That's where that whole mapping is kept of those Pages talk about pages in a moment every time you do a context switch that memory map gets changed and That's where that overhead comes right your context switching overhead where you have to go change that mapping Okay So again back to our map here we've got this this view of the 32-bit world and Every time we change the process this whole set of mappings in here into the space is going to change So back to the MMU All right So we use that to manage those virtual address mappings and so I already hinted at page So how does this done it works on the granularity of a unit called a page? Okay? and Some architectures people always hear 4k Some architectures most architectures. They're configurable There's some advanced features some very large page types. We're not going to get into that Today, but here's some common ones right 4k 4k or 64k and arm 64 Like I say, we're not going to talk about huge pages. That'd be a more advanced topic, but let's just assume 4k for This talk since that's what's most most architectures are defaulting to so that's our unit of memory that the MMU can work with right? We're lined on that page size anytime we do any allocations or mappings All right, and then we have this concrete concept, which is the page frame Okay, and that's page size page align unit of memory of physical memory so anytime we say page frame that means in that physical memory map, okay, and When we talk about a page that's the unit for virtual addressing purposes that the MMU is dealing with Okay, and so you'll see that abbreviation pfn throughout the memory management code That's your page frame number right referring to that page frame physical unit Okay, so MMU operates on pages right memory map for process is going to have this huge list of mappings, right? Big space a bunch of scattered page frames all over the place, right a range of multiple pages and so What does the TLB need to know right the TLB when when it actually gets loaded with a mapping right a virtual address the physical address? So page page frame, right and then a set of permissions right rewrite execute Back to our view of that right just as a reminder All right So as we were we touched on earlier If we act access a region of memory right that we don't have mapped we're gonna get a page fault exception Okay, and this is normal right these are good things we want this page fault exception Okay, and I mentioned that TLB is very in size, you know some of the embedded stuff They have 16 entries in it. It's not much when we know that our page size is 4k, right? And so that's got a lot of churn in it. Okay, and so when we context switch We have a lot of page faults as we start touching Virtual addresses that aren't mapped right so your process gets swapped or context switched in you start Executing code. It's touching you get page faults that exception because we don't have a mapping right and We also have a concept a lazy allocation. We'll talk about in detail here All right, so this is what it looks like visually in between you've got your virtual address It's hitting the TLB, and then it's able to touch those physical page frames right through those mappings that are set up All right, so mapped page ranges All right, so contiguous set say the text for your application your process some data area that's mapped and Those are going through the TLB to access actual backing page frames for that area And then you'll have some on map space that maybe hasn't been executed yet Notice that's the allocated frames on that side that's going through there. All right So just just as I mentioned with kernel virtual addresses and that V malik space It's not guaranteed to be contiguous. Okay in in user space virtual addresses All right, so don't rely on that. We already said that's why you can't use them for DMA All right, and one of the reasons for that is it makes it much easier to allocate memory if you get into how the internal memory allocators Work and and think about how how fragmented things get this allows you to go put together a large allocation with a lot of scattered page frames, right and and Almost everything you do it doesn't require physically contiguous page frames backing your code All right so As we're saying when we looked at that that virtual address and it's and we said the virtual address space Say in 32 bit in that 3 gig area We said one of the cool things was that each process gets its own address space So what does that mean you hear that all the time? It means that when you look at the virtual address space and say you look at that task struct and that mm You're gonna see mappings that have that same virtual address But they're pointing to all different physical memory addresses all over the place So if they're in there at the same if you have things scheduled Running next to each other. They're using the same virtual address right they get scheduled in but it's mapped Right to a different page frame each time so but they don't have to know about that backing and so Here's an example Process one with this set of Virtual addresses map through all these different page frames right in the blue and then process two has got these same virtual addresses and He's he's touching completely different page frames right just visually representing that okay Now we get into shared memory right well we need to for IPC purposes shared memory is a common concept a posix concept Normal concept in most OS's and and so shared memory using MMU and we saw how we can have the same virtual address with different page frames right We can have different virtual addresses pointing to the same page frames is essentially how shared memory works right so simply map the same physical frame to Two different processes right the virtual addresses don't have to be the same and Now you have shared memory right two different processes completely different virtual addresses But they're touching that same page frame as they get context switched in okay, and how does that look? We get the shared physical frame down there in green right we've got this virtual address mapping to it It's touching that shared frame right this is a 4k shared Memory space and then this completely different virtual mapping in the other process pointing to the same frame boom we've got shared memory Now So that was a case with with different virtual addresses okay The M-Map system calling may be familiar with right you can get at a specific Address to share the memory so that's That's a different case okay, and it can fail All right, let's talk about lazy allocation So one of the things you will notice when you work on a Linux system or a classic Unix system is that the kernels not going to allocate memory directly Well, yeah, you saw your your call actually come back successfully Right you got virtual memory, but it didn't actually allocate the physical memory of those page frames that back it right? And that's what we call lazy allocation So this is optimization right the kernels are going to wait until you actually need to use that memory So if you're allocating a four megabyte chunk of memory for your database And you haven't touched any yet. It didn't really allocate anything for you right? If you if you never use it you never touch it it never allocates anything All right, so how does this work? So when we we request that memory it just Creates this record of the request in the page tables talk about page tables in a moment returns the process And so you've got that virtual memory set aside in the user space process Okay, once we touch it our old friend the page fault comes into play right? We already learned that we're going to get an exception right because there's there's no mapping there right or it's only set to read permissions right and We're going to go do a page fault handler so Kernels going to use page tables See that the mapping is valid in this case in a lazy allocation right allocated virtual address space But it's not yet mapped in the TLB, okay? At that point it's going to allocate those page frames a page frame a series of it whatever the request needs to be satisfied with okay, and Then it's going to update the TLB. It's architecture specific how that happens of course with that mapping And then he comes back from the exception handler and the user space program continues. So You your malloc got you that Virtual address space and return quickly but when you went to touch the memory all of this happened behind the seeds right the first time You went to dereference that pointer and update it with a value So that's what's happening behind the scenes okay, but you're not aware of that key point here right? But you will see it if you're running Benchmarking and you see that lag right it's appreciable right and you can use you can use tracing tools and see how that's Happening visually The other thing if you have time-sensitive Things here right you know that you have a fast path You can go Preallocate that you may have used mLoc or the family mLoc calls That will go ahead and preallocate these things so you don't have that lazy allocation situation So as we said getting into page tables tlb entries could be the entries into tlb Can be a limited resource right we can't just map the whole world of our address space in there right? So we have a lot more mappings in that struct mm for our process than we have tlb entries So the kernels got a track all that so it has a set of data structures. We call the page tables, okay? and you can look in struct mm and VM area struct to see how those are done and But it's essentially a hierarchy that leads you down to that 4k page Right and the associated mapping to page frame number and the permissions right so everything lines up with what needs to get Loaded into the tlb's Okay, and also has metadata in addition to that about is it valid or not and so forth and some other housekeeping Flags as well, okay? So When we have something the page table in a tlb we so we have a valid mapping Right, and you touch it the hardware since there's nothing in a tlb yet is going to generate that page fault right? CPU doesn't have the knowledge CPU the mmU right only a kernel does All right, so our page foot handler runs right it's gonna traverse these page tables Find that mapping for the virtual address right page granularity Select and remove an existing tlb entry create a new one with our address and the correct permissions and so forth and Come back to the user space process. Okay? all right swapping and And Good alright So swapping we're used to our systems. We do deal with our desktop systems our development systems Where we have a lot of swapping out to our disk when they're doing heavy builds, right? I'm running low on RAM and You know how this works is the mmU is the thing that enables this okay, and so you're gonna run out of that 16 gig RAM you have under these heavy builds and You're gonna context switch and it needs more memory and it's gonna take those page frames that were backed and It's gonna take the contents of those and it's gonna push them out to your storage right and then When you need that data back and you've been context switch back in it's gonna read that back off that slow storage and Bring it back in that's the big picture right so Low-level details, right? It's gonna do that on a frame base basis, right? It's gonna copy a frame to the disk remove the tlb entry and then that frame is free to be backed for another process right So when we need it again, right CPU generates page fault right common theme here, right? We we flush that entry out of the tlb, right? so now it's gonna generate a page fault and then when we we hit that page fault process sleeps we copy that frame from the disk into an unused frame and We update that page table entry and then wake the process back up Okay, so it's gonna be slow process right we got to go out to that block. I owe or throttled by that bandwidth now And so when we restore the page to RAM, okay? We're not necessarily getting the same page frame. So again, we have this virtual dance going on here, right? There is no persistence or affinity to that original physical page frame So you need to get rid of this notion that paid, you know physical addresses matter, okay? You will use the same virtual address though, right? Because those mapping stay the same in user space. All right, so you don't know the difference. So your code's executing along you yield the processor It gets swapped out You context switch back in it could it'll it'll redo that that mapping same virtual address And your code continues on at the same virtual address But a completely different backing as it the freight page frame context gets copied back in and then mapped in okay? Again, this is that low-level detail why we said we can't use user space virtual Addresses for DMA. We have no persistence of the physical backing that the DMA engines in the peripheral hardware need All right, so what does this look like visually? We've got this frame that was selected By the kernel to be swapped out to our disk. We've got this wonderful trash can looking cylindrical discs thing here and We copy that frame out to the swap media We invalidate the TLB entry page table entries invalid now, right? Okay, and Now there's there's no entry there So that that frames freed up so now you can free it back into the allocator pool But the data is preserved out there on disk. That's in your swap partition. All right. All right now We go we get we get context switch back in right we're back and running same process We try to access that same virtual address. We were just running when we got so rudely taken off the CPU and We get the page fault thing we've been through the page fault dance before and we just rock on through that We get copied from so swap this cylindrical simple disk thing and Put back into that page frame that we got allocated Create the TLB entry But I had one more animation yeah, and Then we return to user space Now we can access that virtual address. We've got the same data. We had before we got swapped out. All right, so I'm actually running this on time beyond so I win. All right It's 95 slides So user space We've got several ways So so we've been through that whole stack all the major pieces of how everything's happening in the background now now Let's see how this maps into you know our apis we have in user space right and So we have several ways That we allocate memory right We've got all our family of Alec things and I've referenced them a couple times verbally right we know that we can M map To directly allocate and map pages. We often see that to map some peripheral IO If we're hacking around not doing proper kernel drivers We have break and s break where we can modify the heap size right So first off met M map right One way that we allocate a Bunch of memory from user space right You'll see it if you if you if you live the world of running s trace on things You see lots of M map happening right when the files are getting Opened and so forth So if you use map anonymous you get you get allocated Normal memory the shared flag allows us to share that memory with other processes All right, so break. Why is it called break? That's the top of the program break legacy terminology right and so Effectively you increase the heap size with that as we're saying okay Now lazy allocation going back to our whole lazy allocation technique, okay We have a situation with with if we look at M map dot C and do break That it's implemented a lot like M map. All right, so it goes in it modifies page tables We talked about how that happened right where we modify the page tables and then we wait for a page fault Okay, and the other thing you can do is you can pre fault Who we talked about with M lock right and not have that issue where with with accessing the memory you have this long lag Relatively long lag where it actually has to allocate that big big chunk of page frames for you All right, so you can you can take that cost up front With M lock and then have relatively deterministic behavior once you're actually accessing the memory the implementations of malloc and calc Sort of the same thing They're gonna use break or M map depending on how big the allocation is and that's gonna happen behind the scenes right and If you if you are astute you can modify that behavior with malopt You could set the threshold parameter to say where where one kicks in or not that's often used in system tuning, okay, and then finally a stack If a process goes beyond a stack right CPU is also gonna trigger a page fault, okay One of the special things the page fault handler does in this case Right is it's gonna detect that you got an address just beyond beyond the stack It knows where that's at right and then it can allocate a new page, right? So it allocate another pfn Go into the page tables map that in drop it in the TLB and Remember pfn could be anywhere. It's not physically contiguous. It's just virtually contiguous. So It's faulted in Execution continues on and it's able to you know drop stuff on that segment of the stack You can see how that works and do page fault That's the arm version And So quick summary Like I said introduction. So if you're already a kernel expert you probably know all that but we went through physical memory, right? We looked at a stock You know x86 familiar memory map we talked about virtual memory three types, right? Kernelogical kernel virtual user virtual which ones are contiguous or not, right? We use Kernelogical for DMA We went through user space addressing how Processes will not have contiguous physical memory and how Swapping page faults work to do lazy allocation and so forth Like I say we cover swapping and then how those user space APIs map on to all that So that's it for the intro. I've got one minute For questions Yes way in the back Okay, so so first part first part of the question let me address that so the question was well If the kernel always has the mappings, right and you're talking about that kernel logical Mapping that has why do we have to wait for this expensive mapping to user space and that that so to answer that And hopefully I'm answering the right question The reason for that is those those Kernelogical mappings if we just use those it would be just like that single address system without an MMU and I can tell you that There's there's systems that in the 90s that had MMUs that running our tosses like VX works They would map with the MMU just flat address space because they had to have the MMU on for performance reasons But you were you you don't without without having your own process space, right? You would have to link everything in its own address space and everything so Kernelogical addresses are nice and linear and easy to think about but You have to do these remapping For user space to have that nice world that we enjoy of that protected per user process address space where you just Write a program link it and it'll run in any context, right? If we had all one mapping of the Kernelogical spaces be just that single address space You'd have to link your program at zero and one bazillion two bazillion and manage them Not stomping on each other as you allocated the memory. I Hope that answers the first part of it and I'm out of time, but we can talk about the second one Yep, sorry 95 slides, so