So far, I implemented kernel memory management, basic process management (only for kernel processes) and other handy stuff. I think it's time to do the *real* thing
My question: in how far does the user memory management differ from the kernel one? And do user processes use the same malloc() routine as the kernel does?
Some hints/links to sites that handle these topics would be great.
User memory management
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:User memory management
the user process usually don't reuse the malloc() function of the kernel because calling it would require too much overhead.
It usually has a malloc() function in the library that may sometimes call a system service to extends the amount of virtual memory the process can access (its heap) -- under linux, this is the SBRK() system call ...
It usually has a malloc() function in the library that may sometimes call a system service to extends the amount of virtual memory the process can access (its heap) -- under linux, this is the SBRK() system call ...
Re:User memory management
Alright, so when creating a user process, I set up a page directory for this process (and load it into CR3), I set up the page tables (memory is allocated by using physical memory allocator). When a user wants to have more memory (SBRK), I add entries in the page table.
Is that right? And is that really everything I need to care for? Seems not that much, actually
Is that right? And is that really everything I need to care for? Seems not that much, actually
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:User memory management
that's what you at least have to provide.
Now, you can go further in virtual memory management with services like
Now, you can go further in virtual memory management with services like
- objects sharing : make the same shared libraries use the same physical pages regardless of how much process require it
- copy-on-write : when a process forks, do not make a copy of the whole pages used by this process. Instead, just copy page tables and mark pages as "read only" in both process.
When one of the processes tries to write to a page, then create a copy of it and decrement the "references count" of the page. - files mapping : this is a first version of swapping: create range of addresses which will refer to an external object. Reading a missing page will invoke a file read operation, and written page will be scheduled for write back in the file when the system feels so (if the file is mapped as read/write)