All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rajat Jain" <rajat.noida.india@gmail.com>
To: Rajendra <rpm@solidcore.com>
Cc: kernelnewbies <kernelnewbies@nl.linux.org>,
	Linux Newbie <linux-newbie@vger.kernel.org>
Subject: Re: Why "high memory" in x86?
Date: Thu, 3 Aug 2006 11:29:39 +0530	[thread overview]
Message-ID: <b115cb5f0608022259w40c3f63fr4383e7f9f7873bc4@mail.gmail.com> (raw)
In-Reply-To: <44D187B3.3070007@solidcore.com>

On 8/3/06, Rajendra <rpm@solidcore.com> wrote:
> Ok, it seems like the stuff that i wrote was not quiet clear, let me
> rephrase.
>
>  o When something runs on a processor, processor just understands the
> the privilege
>     level (PL) of the code in case of linux it is either 0 or 3. The
> whole idea of kernel space
>     and user space is an abstraction for understanding and implementation.
>
>  o If the processor has paging enabled (which is always true), then it
> requires to have
>     a page table entry for every page that is accessed be it  PL 0 or PL 3.
>
>  o Now we need some code to manage to whole of the physical memory and
> suitably add
>     or remove the page table entries and we call such a code as kernel
> code.
>
>  o In case of Linux everything that runs on the processor is always a
> part of something called
>     a process. So, every instruction that runs has to be a part of some
> process (except for interrupts)
>     The "process" is again a unix abstraction of grouping certain
> sequence of instructions.
>
>  o We say that the process has access of the whole 4 GB virtual address
> space as the processor
>    can generate that many unique virtual addresses.
>
>  o What we say is, the first three GB address will always run at PL3
> while the next 1 GB will
>     be at PL 0.
>
>  o The top 1 GB address space is called the kernel and is common for all
> processes.
>
>  o When a process is created, the X86 linux creates a page table for
> process's first 3 GB entries
>    as required by the executable running while the last 1 GB is shared
> with all processes
>    as it is the kernel address.
>
>  o Since the kernel code has to be always present and can never be paged
> out, so it's entries
>    are pinned i.e. always present in page tables. Hence we identity map
> the pages i.e. virtual
>    address is same as physical address (except for the MSB nibble which
> is  >= 0xC).
>
>  o Now the question that comes is, what if the physical memory is more
> then 1 GB, so for
>    such a case we call it as high memory and manage it using temp. page
> table entries.
>
>  o One thing we have to note here is that, kernel is the code that
> creates page table entries
>    for user process and sometimes needs to access the pages. Now for
> accessing the pages
>    it needs some entry in the page table that maps the virtual page
> with physical page. For
>    the first 896 MB of physical pages, the entries are identity mapped
> while for the rest we
>    have to first add an entry in page table and mark it as PL0 and then
> only the processor
>    will allow a valid access.
>
>  o If we want to access the high memory with user space addresses then
> kernel will
>    have to find the virtual address in the user space which is free and
> map it to the high
>    memory  and such a mapping will be available only for the process as
> the entries are
>    present in it's page table only. (Page tables are per process in
> linux)
>

Firstly, Thanks a TONN for the above mail (surely clarified all my
doubts)! But just one query.

If the kernel wants to access the high memory, it will map it into the
virtual address space of the KERNEL (3GB -> 4GB), right? Now at this
point, what will happen to the original (identity) mapping of that
kernel virtual memory address (to which it has now mapped the high
memory)?

TIA,

Rajat

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


  reply	other threads:[~2006-08-03  5:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-01  5:48 Why "high memory" in x86? Rajat Jain
2006-08-01  9:18 ` Rajendra
2006-08-01 13:51   ` Dave B. Sharp
2006-08-02  4:25     ` Rajendra
2006-08-02 16:37       ` Ritesh Kumar
2006-08-03  5:20         ` Rajendra
2006-08-03  5:59           ` Rajat Jain [this message]
2006-08-03 10:52             ` Rajendra
2006-08-03 11:55               ` Daniel Rodrick
2006-08-03 18:44                 ` Rahul Iyer
2006-08-03  6:35           ` Ritesh Kumar
     [not found] ` <20060801090248.4aad8a39@thomas.toulouse>
2006-08-01  9:53   ` Rajat Jain
2006-08-01 12:09     ` Rajat Jain

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=b115cb5f0608022259w40c3f63fr4383e7f9f7873bc4@mail.gmail.com \
    --to=rajat.noida.india@gmail.com \
    --cc=kernelnewbies@nl.linux.org \
    --cc=linux-newbie@vger.kernel.org \
    --cc=rpm@solidcore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.