Well, I'll take a stab at this and maybe someone with a little more background in the history of Linux will correct me or add clarification.
Quote:
Originally Posted by khanhlun
1. Why in 32bit system, linux address space is plitted into 2 spaces: 1GB for kernel and 3 for user.
|
I think your question is "why are the two spaces static in size and not variable depending on the kernel size and loaded modules, plus a guess at other memory the kernel might need."
I think that this was the easiest and most reliable way to engineer the kernel. When Linux was initially developed it had a monolithic kernel - everything you needed was compiled and linked into it. Later, they developed loadable modules. This development makes it harder to calculate what you need for storage for your kernel.
In "Mauerer, Wolfgang (2010-03-11). Professional Linux Kernel Architecture (p. 290). John Wiley and Sons. Kindle Edition." the author states:
Quote:
|
The virtual address space of each process starts at address 0 and extends to TASK_SIZE - 1; the kernel address space begins above this. On IA-32 systems with 2^32 = 4 GiB, the total address space is usually split in a 3:1 ratio on which we focus in the information below. The kernel is assigned 1 GiB, while 3 GiB is available to each userspace process. Other ratios are possible but yield benefits only on very specific configurations and with certain work loads, as discussed above.
|
So, I think it was ease of design of the kernel and experience with each architecture that determined the ratio.
There is a great diagram of memory layout in the web page,
http://82.157.70.109/mirrorbooks/lin...-2-SECT-7.html.
When you looked at it, it was much better than the 2G/2G ration that Windows used (uses?) for 32-bit. And 3GB of virtual storage for an application was enormous at the time.
Quote:
|
Why do user processes can share the same space?
|
In not sure of the question. Each process has its own address space, that is, it's own segment and page tables (or whatever they are called in a particular architecture). That's a good thing. Your process thinks it has the whole 4GB (in the case of 32-bit) to itself, minus of course the space for the kernel and the memory that is shared with other address spaces.
In the case of threads, Linux decided to make a thread look like a process (so it has a process ID) in terms of dispatching, but share memory (so all of the related threads use a set of common segment and page tables). (That's my understanding of it and I hope I have the concept right.)
Quote:
|
and why can kernel and user not share 4GB space?
|
They do, but there is a dividing line between where user space memory ends and kernel memory begins. It's just that the line is fixed at kernel compile time. For a process, it is one linear addressable 4GB of virtual memory. And the process "next door" has its own isolated 4GB of virtual memory, but sharing the kernel and a few other areas.
You can look at it like it's a 4 story row of New York City brownstones (
http://en.wikipedia.org/wiki/Brownst...ate_residences), all side-by-side, where they have a wall between each brownstone, but a common 4th floor with no walls. (Not likely to happen, especially not in NYC, but I needed an analogy...)
I hope I interpreted your questions properly. You've gotten a bit into design philosophy that I think we all just accept. There are good reasons for what was done, and the kernel has been enormously successful. Ask your phone, your server, your home router or maybe even your toaster.
