What"s the deal with 1/3G separation between kernel address space and user address space?
What"s the deal with 1/3G separation between kernel address space and user address space?
am 27.03.2008 06:02:46 von Antino Kim
Hi all,
I was looking into Linux kernel documentation, and I ran into one very
fundamental question: Why does Linux divide virtual address space into
1/3G between kernel and user address space?
Please note that I'm not asking "why 1/3G? why not 2/2G?". I was able
to find some discussion online about this matter. However, my question
is more basic - naive, some may say.
Why is there a division at all? As I understand, there occurs a
context switch between user-level process and the kernel when syscall
is made. Then why are we reserving 1G for kernel? Why isn't it
possible to give full 4G address space to the user process, and kernel
gets full 4G space when switched in?
I don't really understand the whole protection domain thing
either...(i.e., using special instruction to make certain range of
memory address visible.) I mean, sure, user process should not be able
to access kernel data structures and so on. But can't that be done
with page table (access control flags)? I mean, one of the reasons to
use virtual memory is for protecting process from each other. Why
couldn't that be directly applied for user process and kernel?
BTW, 1G for kernel means kernel should only reside within this range?
(I highly doubt it....)
For me, without clear understanding on why we need such division, the
scheme seems meaningless, and wasteful (since user space is now 1G
short). I'm sure I have a huge conceptual mess-up somewhere, but I
can't seem to figure out. Please lend me your wisdom! :)
P.S. Since we're in the topic of memory management in Linux, let me
bring in another question that I've been having difficult time with...
What is HIGH_MEM, and why is it important? How is this concept used in
Linux? I had this question since beginning of this year... It's time
to get to the bottom of it. Thank you all.
--
Antino Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
Re: What"s the deal with 1/3G separation between kerneladdress space and user address space?
am 27.03.2008 12:46:01 von roarbr
Antino Kim wrote:
> Hi all,
>=20
> I was looking into Linux kernel documentation, and I ran into one ver=
y
> fundamental question: Why does Linux divide virtual address space int=
o
> 1/3G between kernel and user address space?
> Please note that I'm not asking "why 1/3G? why not 2/2G?". I was able
> to find some discussion online about this matter. However, my questio=
n
> is more basic - naive, some may say.
>=20
> Why is there a division at all? As I understand, there occurs a
> context switch between user-level process and the kernel when syscall
> is made. Then why are we reserving 1G for kernel? Why isn't it
> possible to give full 4G address space to the user process, and kerne=
l
> gets full 4G space when switched in?
I'm no expert on this either, but will try to explain it shortly.
Since userspace applications calls kernel functions (read(), open() and=
so on), those=20
kernel functions used must be mapped in the address space that an appli=
cation may see,=20
i.e. the userspace and kernel space must share the address range. For 3=
2-bit this gives=20
4GB address space in total.
=46or linux the split is 1GB for kernel and 3GB for userspace as you no=
ticed. In those 1GB=20
the kernel code and data structures must be contained, including the vi=
rtual mappings for=20
physical memory.
Please see chapter "Memory mapping and DMA" from Linux Device Drivers (=
LDD) version 2 or=20
3, available online.
http://lwn.net/Kernel/LDD2/ (HTML + PFD versions of chapters)
http://lwn.net/Kernel/LDD3/ (only PDF version of chapters)
Here is a link to the pfd version from LDD3: http://lwn.net/images/pdf/=
LDD3/ch15.pdf
This chapter explains memory management in linux, including this memory=
split, address=20
types, high and low memory, page tables. I think it should cover most o=
f your questions,=20
and perhaps other experts may give additional info.
--
Roar Bj=F8rgum Rotvik
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
RE: What"s the deal with 1/3G separation between kernel address space and user address space?
am 31.03.2008 07:53:34 von Rajat Jain
Hi,
>>
>> Why is there a division at all? As I understand, there occurs a
>> context switch between user-level process and the kernel when syscall
>> is made. Then why are we reserving 1G for kernel? Why isn't it
>> possible to give full 4G address space to the user process, and
>> kernel gets full 4G space when switched in?
I'm not an expert, but if asked, I think performance can be one of the reasons. Assume that a 4G address space is given to all the processes. Hence for every context switch, we'll need to switch the 4G address space. Out of this address space, we know that a BIG chunk (kernel code + kernel data structures) is always the same for all the processes. So why not switch just the pages that the user is going to use. And hence it might be thought that 3G is enough for application, and 1G can be spared for kernel. Hope I'm making some sense...
>
> Since userspace applications calls kernel functions (read(), open()
> and so on), those kernel functions used must be mapped in the address
> space that an application may see, i.e. the userspace and kernel
> space must share the address range.
The user space applications never "call" kernel code / functions. They just make a syscall....
Thanks,
Rajat
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs