mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

             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®