6

In Operating System Design the kernel is most always mapped to a high virtual memory address, thus gaining control of the upper memory part. The space left below is for applications running in user space, as described in an excellent way in "Linux 3/1 virtual address split".

What I'd like to know is, why is this design decision made or why the kernel does not use the lower part of memory? This is not really clear to me, or maybe I've overseen something.

Edit: This question regards virtual addresses and not physical.

Community
  • 1
  • 1
Sebastian
  • 8,046
  • 2
  • 34
  • 58
  • just a guess: a convention, making it easier to remember what part of memory should be protected from user-space code – ren Dec 30 '11 at 23:21
  • Ok, but then the memory for the kernel is always limited, or user space memory is possibly wasted. So, when the kernel needs additional memory (e. g. for loading a module) it could allocate and set specific permissions for securing it (when paging is enabled). – Sebastian Dec 31 '11 at 07:43

1 Answers1

8

Some advantages of/reasons for such a design:

  • Applications don't need to care about the size and location of the kernel and may pretend they're the only ones in the memory, starting at around 0 and spanning upwards, with minimal or no code and data relocations. Applications are hence easier to design and implement and they may be less likely to have bugs related to mememory management.
  • Applications may use smaller/shorter addresses/pointers and hence save some memory.
  • In the x86 CPU, 16-bit and 32-bit address spaces start at virtual address 0 and end at around 1MB (for real and virtual 8086 modes), 16 MB (16-bit protected mode on i80286+) and 4 GB (32-bit mode, unreal mode). Placing the kernel at lower addresses will reduce the range of addresses available to applications (ex: 16-bit app in 32-bit mode or 32-bit app in 64-bit mode) and/or complicate their memory management. Moving the kernel to the top of the virtual address space generally makes sense on the x86.

There may be other reasons, usually platform-specific. On some platforms there may be little to no difference between the two options. Yet on others the preferred kernel location may be at the lower virtual addresses. Details matter.

Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
  • 1
    Ok, this makes a bit more sense to me. But my understanding right now goes like this: The kernel implements virtual memory management thus providing all user applications the ability for relocation at address 0x0. If so then the placement of the kernel in memory does not matter, when the kernel is the only instance controlling memory. Makes sense? – Sebastian Jan 02 '12 at 08:23
  • 1
    Don't forget that before the kernel does any relocation, compilers have to produce relocatable binaries. If every app can start at ~0, the code in the binaries can be simpler, the binaries may not include any relocation info, the compiler can be simpler or do less work. – Alexey Frunze Jan 02 '12 at 08:31
  • I'm aware of that, but this does not affect the compilation of the kernel. If the kernel is compiled with relocation information and implements virtual memory management every app can start at ~0, but (in my opinion) the "position" of the kernel does not matter. – Sebastian Jan 02 '12 at 08:34
  • 1
    Look at the whole system, the kernel and apps. It's often beneficial to make the kernel, one thing, more complex to simplify apps and their development, that is, to simplify many other things. It makes sense since app developers aren't and shouldn't be as technical as kernel developers. Like I said, details matter, including who does what. – Alexey Frunze Jan 02 '12 at 08:43
  • 1
    Ok, based on your comment, I've found the following [Anatomy of a Program in Memory](http://bit.ly/ogDFD) which is actually a great article. And the sentence that got my eye is: "Once virtual addresses are enabled, they apply to all software running in the machine, including the kernel itself. Thus a portion of the virtual address space must be reserved to the kernel". I didn't knew that before and it clarifies all things, so thank you for the "whole system" hint. But now i'm asking myself whether there isn't a better way handling virtual memory, but this does not belong here. – Sebastian Jan 02 '12 at 12:05
  • 1
    @macs a little of topic, but can't hold to share this great resource: [mit 6.828](http://pdos.csail.mit.edu/6.828/2011/). If you go through the labs, you'll get deep understanding of stuff. – ren Jan 02 '12 at 14:02
  • @ren: Actually this is the source where the question came into my mind ;) The provided answer in Lab 2 wasn't satisfying me. Maybe I've also overread the "virtual addresses for everything"-stuff. – Sebastian Jan 02 '12 at 15:16
  • @macs: I don't know systems where page translation is available only to a portion of all the software (e.g. only apps, but not kernel) or where the address space isn't at least partially shared between the kernel and other software (if there's no sharing, how do you communicate between them in an efficient way?). But page translation is very flexible and you may set it up such that for some addresses virtual=physical or virtual=physical+constant. – Alexey Frunze Jan 02 '12 at 16:07
  • @Alex: Maybe one could build up communication using hash values, but this page translation is supported by the CPU (and thus virtual addressed are everywhere, user and kernel space), this would be a software implementation and possibly rather slow. Just a thought ;) – Sebastian Jan 02 '12 at 17:14
  • @macs: hash values or not, you need to pass data somehow between the kernel and everything else, which implies shared memory, registers or other resources. – Alexey Frunze Jan 02 '12 at 19:18
  • @Alex: You're right, right now I'm getting a much clearer picture, thanks. – Sebastian Jan 02 '12 at 20:51