>> In Linux, kernel space is constantly present and maps the same physical memory in all processes. That's right there together with the city states of Greece and other ancient memories. Meltdown and Specter happened.
Explain?
Anatomy of a Program in Memory (2009)
11–20 of 28 posts
Re: Anatomy of a Program in Memory (2009)
#12>> In Linux, kernel space is constantly present and maps the same physical memory in all processes. That's right there together with the city states of Greece and other ancient memories. Meltdown and Specter happened.
Re: Anatomy of a Program in Memory (2009)
#13The author states: >It is also possible to create an anonymous memory mapping that does not correspond to any files, being used instead for program data." This isn't strictly true though is it? It was my understanding even mmap() MAP_ANONYMOUS used a file interface, and that the way the kernel creates anonymous maps is by creating an instance of /dev/zero in tmpfs. Although I believe the file descriptor might be igno…
Re: Anatomy of a Program in Memory (2009)
#14if the process depicted in the diagram were to start a second thread, where would that second thead’s stack go in the diagram? The two threads would share the same heap.
You're totally right though, that threads complicated the traditional "stack grows down heap grows up" view of a Unix user address space.
Re: Anatomy of a Program in Memory (2009)
#15>> In Linux, kernel space is constantly present and maps the same physical memory in all processes. That's right there together with the city states of Greece and other ancient memories. Meltdown and Specter happened.
You could still make an argument for that if you squint hard enough. The virtual memory is still reserved, and a transition to kernel mode still has user space mapped, and the kernel's view of memory as well.
Re: Anatomy of a Program in Memory (2009)
#16Re: Anatomy of a Program in Memory (2009)
#17Earlier quoted context omitted.
You could still make an argument for that if you squint hard enough. The virtual memory is still reserved, and a transition to kernel mode still has user space mapped, and the kernel's view of memory as well.
Thanks for clarifying! Is whatever the kernel does now in transition to user space expensive because it's somehow proportional to the amount of actual memory that the kernel is using or has reserved?
Re: Anatomy of a Program in Memory (2009)
#18After reading many articles about virtual memory and how kernel space is mapped into every process I don't understand why it is necessary. Why can't process only have mapped it's user mode space? Also it only seems to be case of unixes and windows. Not sure how exactly it's done in OSX but "Mac OS X does not map the kernel into each user address space, and therefore each user/kernel transition (in either direction) r…
I say all of this in the past tesnse, since Meltdown makes it possible to read all that kernel memory. Kernels now keep most of the kernel memory unmapped when user mode is executing.
Re: Anatomy of a Program in Memory (2009)
#19After reading many articles about virtual memory and how kernel space is mapped into every process I don't understand why it is necessary. Why can't process only have mapped it's user mode space? Also it only seems to be case of unixes and windows. Not sure how exactly it's done in OSX but "Mac OS X does not map the kernel into each user address space, and therefore each user/kernel transition (in either direction) r…
On x86, I t was presumably for performance, so that the TLB does not have to be flushed when switching from user to kernel mode. x86 requires some kernel memeory to be mapped always, for example the stack for syscall and trap handlers. So by keeping everything mapped into memory, the kernel did not have to worry about which parts were needed to handle syscalls and which were not. These kernel pages were marked as “su…
Re: Anatomy of a Program in Memory (2009)
#20After reading many articles about virtual memory and how kernel space is mapped into every process I don't understand why it is necessary. Why can't process only have mapped it's user mode space? Also it only seems to be case of unixes and windows. Not sure how exactly it's done in OSX but "Mac OS X does not map the kernel into each user address space, and therefore each user/kernel transition (in either direction) r…
On x86, I t was presumably for performance, so that the TLB does not have to be flushed when switching from user to kernel mode. x86 requires some kernel memeory to be mapped always, for example the stack for syscall and trap handlers. So by keeping everything mapped into memory, the kernel did not have to worry about which parts were needed to handle syscalls and which were not. These kernel pages were marked as “su…