Where is the i686 kernel

Kreg Schlosser liberaltugboat at gmail.com
Wed May 25 02:01:56 UTC 2005

umm this has nothing to do with the memory addressing limit of a 32
bit processor
it has to do with the 386 kernel (as in 386 the proccessor not the architecture)
the default kernel is built to be compatible with a 386 processor and
one of the limits of the kernel is not being able to address more then
887 mb ram
current processors like the p4 and amd k7 use 686 architecture thats
why they compile a kernel that is optimized for those processors.  the
686 (and k7) kernels do not have the memory limitation.
I dont want to start a flame war but this is a well known situation
with ubuntu here is the wiki page explaining it:

On 5/23/05, James Wilkinson <ubuntu at westexe.demon.co.uk> wrote:
> mrbass wrote:
> > ok I upgraded to 686 and it sees the entire 1GB of memory.  Wow can't
> > believe 2005 and have these kinda of issues.  I thought the issues were
> > seeing more than 4GB of memory..hehe.
> As you get closer to the architectural limit (for a 386) of 4 GB,
> certain optimisations become impossible.
> 4 GB would be a hard limit if Linux didn't use virtual memory. As it is,
> the MMU is responsible for taking pages from memory, page space and thin
> air, and turning it into an "address space" that processes find sane.
> With under 1 GB of memory, Linux can set up virtual memory so that 3 GB
> are available for processes (this would have to include a lot swapped
> out to disk). The whole of real memory can be mapped into the other GB,
> along with any memory mapped from PCI devices (it's that memory that you
> found was "lost": do you have a 128 MB graphics card?)
> This GB of memory is protected (by the MMU hardware) so normal processes
> can't get at it. When Linux switches from user mode into kernel mode,
> this GB is made available, so the kernel space can use it immediately.
> The alternative involves setting up a kernel address space for certain
> tasks (not too much of a problem) and "flushing" (invalidating) the
> MMU's "translation look-aside buffer" (TLB). Twice: once going in, once
> going back to user mode.
> Now the TLB is what makes the whole virtual memory lark practical in the
> first place. The MMU has to rewrite each and every memory access: the
> TLB is effectively a cache to tell the MMU how to do it. Otherwise, it
> has to look at memory itself to find out how to rewrite the memory
> access: this involves at least two lookups, depending on the
> architecture.
> So when you flush the TLB, the MMU has to go back to memory several
> times for each access. And this slows the computer down.
> Linux's "map main memory and protect it" approach, along with other
> tricks, makes the system call overhead *very* low compared with other
> OSes. (I.e. certain sorts of programs and certain sorts of uses will run
> noticeably faster).
> The 2005 solution is a much larger virtual address space: for that, you
> need a 64 bit computer and OS.
> James.
> --
> E-mail address: james | "Hardware simply does not work like the manual says
> @westexe.demon.co.uk  | and no amount of Zen contemplation will ever make you
>                       | at one with a 3c905B ethernet card."
>                       |     -- Alan Cox
> --
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-users

More information about the ubuntu-users mailing list