From: linux@horizon.com
To: middle.fengdong@gmail.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: The 3G (or nG) Kernel Memory Space Offset
Date: 30 Aug 2006 00:32:08 -0400 [thread overview]
Message-ID: <20060830043208.14311.qmail@science.horizon.com> (raw)
Just to answer the question in elementary terms:
This is because:
- On x86, the user and kernel share the available 4G virtual address space,
- User space gets first choice, and so takes the low 3G.
- The kernel thus has to use the high 1G, and if it wants a copy
of physical memory, that's the only place it can go.
In somewhat more detail:
1) In standard x86 Linux, the user and kernel address spaces share the 4
GB virtual address space of the x86 processor. There are other ways
to do it (see the 4G+4G patch for an example), but they're slower.
x86 processors only support one set of page tables at a time, and
changing is a slow operation. Other processors let you have separate
user and kernel page tables active simultaneously, but x86 does not.
So for speed, you don't want to change page tables to make a system
call. Also, many system calls are passed pointers to buffers in user
memory, so need to access user memory. It's fastest and easiest to do
this if user memory is in the address space when executing kernel code.
Fortunately, x86 page tables have a "user" bit in each page table
entry, that can make pages only accessible from the kernel. They are
still in the user's virtual address space, but can't be accessed.
Thus, it is possible for the user and kernel to share the address space.
So, given all of this, Linux (as well as most other operating systems)
on x86 has decided to divide the 4 GB virtual address space into "user"
and "kernel" parts. As far as the user is concerned, the kernel part
is just "missing", so it's made as as small as reasonably possible.
2) The division chosen is that the user gets the low 3G of the address
space, and the kernel gets the high 1G. x86 ABI standards require
that user space gets low addresses, and in any case, the kernel exists
to make user-space programs happy.
3) The kernel finds it convenient to have a copy of physical memory in its
address space, so it maps one. If there's more RAM than will fit in the
kernel address space, the HIGHMEM patches provide an alternative.
Since this is an elementary explanation, I won't describe how that works.
Thus, the physical memory map used in the kernel ends up offset by 3G.
next reply other threads:[~2006-08-30 4:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-30 4:32 linux [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-08-29 14:15 Dong Feng
2006-08-29 14:32 ` Andi Kleen
2006-08-29 14:36 ` Jan Engelhardt
2006-08-29 16:01 ` Dong Feng
2006-08-29 16:05 ` Arjan van de Ven
2006-08-29 16:30 ` Jan Engelhardt
2006-08-29 16:44 ` Jeremy Fitzhardinge
2006-08-29 16:12 ` Christoph Lameter
2006-08-29 16:16 ` Dong Feng
2006-08-29 16:42 ` Jeremy Fitzhardinge
2006-08-29 18:37 ` Peter Grandi
2006-08-29 21:15 ` Jeremy Fitzhardinge
2006-08-30 6:11 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060830043208.14311.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=middle.fengdong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®