lkml.org 
[lkml]   [2005]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Why does the kernel need a gig of VM?
On Fri, Jan 28, 2005 at 03:06:15PM -0500, John Richard Moser wrote:
> Can someone give me a layout of what exactly is up there? I got the
> basic idea
>
> K 4G
> A 3G
> A 2G
> A 1G
>
> App has 3G, kernel has 1G at the top of VM on x86 (dunno about x86_64).
>
> So what's the layout of that top 1G? What's it all used for? Is there
> some obscene restriction of 1G of shared memory or something that gets
> mapped up there?

By default, the bottom 1G of physical memory is mapped into the 1G of
KVA. (If you have less than 1G, it's all mapped.) Thus, the TLB
remains valid across the user/kernel switch, which makes system calls
much faster.

The 4G/4G patches (google for the lwn.net overview) change this,
introducing a TLB flush on every syscall. Better for some things
because you get more VA space, worse for most things because it's
slower. (But it's "lots better for a few" versus "a little worse for
everybody", so the tradeoff is often worthwhile.) [1]

So the answer to your question is, "What's up there? Memory. All of it."
(Until you get to highmem.)

[1] The 4G/4G patch's *primary* goal is to increase the amount of KVA
available to allow more "struct page" entries without exhausting
lowmem. Trying to manage 32GB or 64GB of physical memory with only
896MB of lowmem is very difficult. It has the additional advantage
of allowing userland to mmap almost 4GB of stuff (as compared to
almost 3GB without 4G/4G) which can be a nice win for database-type
apps.

-andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" 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.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.066 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site