By: Tzvetan Mikov (tzvetanmi.delete@this.yahoo.com), May 14, 2007 4:40 pm
Room: Moderated Discussions
rwessel on 5/14/07 wrote:
---------------------------
>I pretty sure that no one, Intel and MS included, thinks PAE is a better solution than a straight 64 bit OS.
>
>And everyone understands that it has some pretty solid limitations. Linus and
>others (myself included) have discussed the kernel space issues at length (simply
>considering the size of the data structures needed to manage all those physical
>pages demonstrates the problem, and that's not the only issue), and it's hard to
>see how a 32 bit OS could actually make use of much more than about 64GB of memory.
>And even that's something of a stretch (for example, you can't use the /3GB user
>address space option in Windows with more than 16GB of RAM, IIRC).
>
>I'm sure that's part of the reason why Intel never defined (until x86-64) support
>for more than an additional four address bits in PAE (which limits you to 64GB).
>
>OTOH, in many situations, adding (some) PAE support to an OS is/was much simpler
>than doing a 64 bit port of the OS especially once you start counting all the device
>drivers and whatnot (and Linux is something of a special case where that port is actually fairly easy).
>
>Is especially simpler if you can limit the generality of the extended pages somewhat
>(or a lot), and for certain applications (databases, paging, caching, for example),
>something like PAE is pretty easy to use.
>
>And from a hardware context, PAE was a basically trivial change in the page table formats.
>
>So PAE was a quick and easy way to provide some support for more than 4GB of physical
>address space. Is a straight 64-bit OS (supporting 32 bit applications) better?
>Yes. But getting there from here is the problem. And for most users, the limitations
>of a 32-bit OS don't start to bite until you get somewhere past 2GB of RAM, so what
>the motivation for accepting any degree in inconveniece associated with a 64-bit version of the OS?
>
You are right, of course, although I don't quite understand why you brought up PAE. I was explicitly talking about less than 4 GB RAM. There has been some confusion on this because in Linux anything above 1 GB is considered HIGHMEM. This however is a design decision specific to Linux and is not necessarily an absolute requirement for a 32-bit x86 OS.
If your applications do not _individually_ require more than 2 GB address space, and if your RAM plus your PCI devices is <= 4 GB, why do you really need a 64-bit OS ?
Let's see. Fundamentally, what does the OS kernel need address space for ? Let's assume a 3G:1G user/kernel split.
a) For its own code and data structures, including page tables. 1 GB should be more than sufficient for that on a 32-bit system.
b) For memory-mapped hardware. With graphics cards with 512MB RAM and more this can be a problem on 32-bit systems. A solution is to map such hardware only in user space.
c) In a system call the OS kernel has to be able access the entire address space of the calling process. Obviously this is not a problem, as the kernel can use the user addresses directly.
d) Sometimes the kernel has to access parts of the address space of an arbitrary process. Since it needs only parts, not the entire space, it can lock & map the necessary address pages to kernel space. Windows does this persistently (the pages are mapped in advance). 32-bit Linux ends up doing it dynamically - it maps a page if it needs it and it is > 1 GB, and then unmaps it ASAP.
e) For caches. This is the only problematic part. Ideally the kernel should be able to use all available RAM as cache, but it can't fit all in the kernel address space. However since this is a specialized data structure, it should be possible to map memory in & out as needed.
Am I missing something ?
The point is, the OS doesn't need generic access to all memory at all times. So, unless your applications require lots of virtual address space, having 2-3G of RAM doesn't necessarily have to be a cause for moving to 64-bit.
regards,
Tzvetan
---------------------------
>I pretty sure that no one, Intel and MS included, thinks PAE is a better solution than a straight 64 bit OS.
>
>And everyone understands that it has some pretty solid limitations. Linus and
>others (myself included) have discussed the kernel space issues at length (simply
>considering the size of the data structures needed to manage all those physical
>pages demonstrates the problem, and that's not the only issue), and it's hard to
>see how a 32 bit OS could actually make use of much more than about 64GB of memory.
>And even that's something of a stretch (for example, you can't use the /3GB user
>address space option in Windows with more than 16GB of RAM, IIRC).
>
>I'm sure that's part of the reason why Intel never defined (until x86-64) support
>for more than an additional four address bits in PAE (which limits you to 64GB).
>
>OTOH, in many situations, adding (some) PAE support to an OS is/was much simpler
>than doing a 64 bit port of the OS especially once you start counting all the device
>drivers and whatnot (and Linux is something of a special case where that port is actually fairly easy).
>
>Is especially simpler if you can limit the generality of the extended pages somewhat
>(or a lot), and for certain applications (databases, paging, caching, for example),
>something like PAE is pretty easy to use.
>
>And from a hardware context, PAE was a basically trivial change in the page table formats.
>
>So PAE was a quick and easy way to provide some support for more than 4GB of physical
>address space. Is a straight 64-bit OS (supporting 32 bit applications) better?
>Yes. But getting there from here is the problem. And for most users, the limitations
>of a 32-bit OS don't start to bite until you get somewhere past 2GB of RAM, so what
>the motivation for accepting any degree in inconveniece associated with a 64-bit version of the OS?
>
You are right, of course, although I don't quite understand why you brought up PAE. I was explicitly talking about less than 4 GB RAM. There has been some confusion on this because in Linux anything above 1 GB is considered HIGHMEM. This however is a design decision specific to Linux and is not necessarily an absolute requirement for a 32-bit x86 OS.
If your applications do not _individually_ require more than 2 GB address space, and if your RAM plus your PCI devices is <= 4 GB, why do you really need a 64-bit OS ?
Let's see. Fundamentally, what does the OS kernel need address space for ? Let's assume a 3G:1G user/kernel split.
a) For its own code and data structures, including page tables. 1 GB should be more than sufficient for that on a 32-bit system.
b) For memory-mapped hardware. With graphics cards with 512MB RAM and more this can be a problem on 32-bit systems. A solution is to map such hardware only in user space.
c) In a system call the OS kernel has to be able access the entire address space of the calling process. Obviously this is not a problem, as the kernel can use the user addresses directly.
d) Sometimes the kernel has to access parts of the address space of an arbitrary process. Since it needs only parts, not the entire space, it can lock & map the necessary address pages to kernel space. Windows does this persistently (the pages are mapped in advance). 32-bit Linux ends up doing it dynamically - it maps a page if it needs it and it is > 1 GB, and then unmaps it ASAP.
e) For caches. This is the only problematic part. Ideally the kernel should be able to use all available RAM as cache, but it can't fit all in the kernel address space. However since this is a specialized data structure, it should be possible to map memory in & out as needed.
Am I missing something ?
The point is, the OS doesn't need generic access to all memory at all times. So, unless your applications require lots of virtual address space, having 2-3G of RAM doesn't necessarily have to be a cause for moving to 64-bit.
regards,
Tzvetan
Topic | Posted By | Date |
---|---|---|
Rock/Tukwila rumors | mas | 2007/05/05 11:59 AM |
Rock/Tukwila rumors | David Kanter | 2007/05/05 01:33 PM |
Rock/Tukwila rumors | Dean Kent | 2007/05/05 02:35 PM |
K8 vs Win64 timeline | anonymous | 2007/05/05 05:19 PM |
Yes, I misremembered... | Dean Kent | 2007/05/05 09:03 PM |
Rock | Daniel Bizó | 2007/05/06 01:34 AM |
Rock | Dean Kent | 2007/05/06 06:11 AM |
Rock/Tukwila rumors | Joe | 2007/05/06 10:24 AM |
Rock/Tukwila rumors | Dean Kent | 2007/05/06 10:49 AM |
Rock/Tukwila rumors | Linus Torvalds | 2007/05/06 11:09 AM |
Rock/Tukwila rumors | anon | 2007/05/07 12:32 AM |
Rock/Tukwila rumors | Rakesh Malik | 2007/05/07 08:36 AM |
Rock/Tukwila rumors | Michael S | 2007/05/07 09:06 AM |
Rock/Tukwila rumors | anon | 2007/05/07 08:48 PM |
Rock/Tukwila rumors | Rakesh Malik | 2007/05/08 05:45 AM |
Rock/Tukwila rumors | anon | 2007/05/08 04:30 PM |
Wow. (nt) | Brannon | 2007/05/08 05:16 PM |
Rock/Tukwila rumors | rwessel | 2007/05/08 08:48 PM |
Rock/Tukwila rumors | JS | 2007/05/08 09:07 PM |
Rock/Tukwila rumors | JS | 2007/05/09 05:44 AM |
Rock/Tukwila rumors | Rakesh Malik | 2007/05/09 04:35 AM |
Much ado about x | Michael S | 2007/05/09 08:39 AM |
Call it x86-64 | Linus Torvalds | 2007/05/09 09:27 AM |
(i)AMD64 | Michael S | 2007/05/09 11:16 AM |
(i)AMD64 | Linus Torvalds | 2007/05/09 11:29 AM |
(i)AMD64 | Groo | 2007/05/09 03:45 PM |
TIFNAA | anonymous | 2007/05/09 04:49 PM |
Inspired by FYR Macedonia? (NT) | Michael S | 2007/05/09 10:21 PM |
More likely... | rwessel | 2007/05/09 11:39 PM |
TIFNAA | Gabriele Svelto | 2007/05/09 10:57 PM |
(i)AMD64 | James | 2007/05/10 01:27 AM |
i86 | Dean Kent | 2007/05/09 11:30 AM |
(i)AMD64 | Max | 2007/05/09 12:28 PM |
wide86? long86? | hobold | 2007/05/10 04:05 AM |
x87 perhaps, it is one more. :) (NT) | Groo | 2007/05/10 04:50 AM |
x86+ | Dean Kent | 2007/05/10 07:44 AM |
Does it really matter? | Doug Siebert | 2007/05/10 08:10 AM |
let's stay with x86-64 for now, please | Marcin Niewiadomski | 2007/05/10 10:50 AM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/11 05:11 AM |
let's stay with x86-64 for now, please | rwessel | 2007/05/11 01:46 PM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/11 05:03 PM |
let's stay with x86-64 for now, please | Michael S | 2007/05/12 09:49 AM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/12 12:05 PM |
let's stay with x86-64 for now, please | Michael S | 2007/05/12 12:25 PM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/12 02:39 PM |
let's stay with x86-64 for now, please | JasonB | 2007/05/13 06:43 AM |
client consolidation | Michael S | 2007/05/13 07:37 AM |
let's stay with x86-64 for now, please | Tzvetan Mikov | 2007/05/13 02:44 PM |
let's stay with x86-64 for now, please | rwessel | 2007/05/14 01:42 PM |
What's your point? | Doug Siebert | 2007/05/11 01:56 PM |
What's your point? | Linus Torvalds | 2007/05/11 03:15 PM |
What's your point? | Doug Siebert | 2007/05/13 02:11 PM |
What's your point? | Dean Kent | 2007/05/13 06:04 PM |
What's your point? | JasonB | 2007/05/14 01:06 AM |
What's your point? | Dean Kent | 2007/05/14 06:20 AM |
What's your point? | JasonB | 2007/05/14 03:35 PM |
What's your point? | JasonB | 2007/05/14 06:35 PM |
What's your point? | Dean Kent | 2007/05/14 07:12 PM |
What's your point? | Dean Kent | 2007/05/11 05:06 PM |
What's your point? | Stephen H | 2007/05/13 12:55 AM |
Why didn't MS take advantage of PAE? | David W. Hess | 2007/05/13 07:37 AM |
PAE sucks (Why didn't MS take advantage of PAE?) | Linus Torvalds | 2007/05/13 09:20 AM |
PAE sucks (Why didn't MS take advantage of PAE?) | Dean Kent | 2007/05/13 09:49 AM |
PAE sucks (Why didn't MS take advantage of PAE?) | David W. Hess | 2007/05/13 11:37 AM |
> 1 GB RAM on a 32-bit system | Tzvetan Mikov | 2007/05/13 12:44 PM |
> 1 GB RAM on a 32-bit system | S. Rao | 2007/05/13 02:00 PM |
> 1 GB RAM on a 32-bit system | Tzvetan Mikov | 2007/05/13 04:32 PM |
> 1 GB RAM on a 32-bit system | S. Rao | 2007/05/13 11:19 PM |
> 1 GB RAM on a 32-bit system | Linus Torvalds | 2007/05/13 02:46 PM |
> 1 GB RAM on a 32-bit system | Tzvetan Mikov | 2007/05/13 04:23 PM |
> 1 GB RAM on a 32-bit system | JasonB | 2007/05/13 05:37 PM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/13 07:31 PM |
Windows manages memory differently | JasonB | 2007/05/14 12:50 AM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/14 07:56 AM |
Windows manages memory differently | rwessel | 2007/05/14 02:40 PM |
Windows manages memory differently | David W. Hess | 2007/05/14 03:07 PM |
Windows manages memory differently | rwessel | 2007/05/14 03:51 PM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/14 04:40 PM |
Windows manages memory differently | rwessel | 2007/05/14 05:09 PM |
Windows manages memory differently | Howard Chu | 2007/05/14 10:17 AM |
Windows manages memory differently | Jukka Larja | 2007/05/14 10:30 AM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/14 12:54 PM |
Windows manages memory differently | Howard Chu | 2007/05/15 02:35 AM |
Windows manages memory differently | Groo | 2007/05/15 06:34 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | Matt Sayler | 2007/05/15 05:23 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | Wes Felter | 2007/05/15 07:37 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | Anonymous | 2007/05/15 09:49 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | anon2 | 2007/05/15 06:13 PM |
PAE sucks (Why didn't MS take advantage of PAE?) | Paul | 2007/05/13 02:40 PM |
PAE sucks (Why didn't MS take advantage of PAE?) | Peter Arremann | 2007/05/13 04:38 PM |
PAE sucks (Why didn't MS take advantage of PAE?) | Henrik S | 2007/05/14 02:31 AM |
The fragility of your argument | slacker | 2007/05/13 02:56 PM |
The fragility of your argument | nick | 2007/05/13 04:42 PM |
The fragility of your argument | Howard Chu | 2007/05/14 01:52 AM |
The fragility of your argument | Dean Kent | 2007/05/14 08:19 AM |
The fragility of your argument | anon2 | 2007/05/14 07:26 AM |
The fragility of your argument | Tzvetan Mikov | 2007/05/14 08:01 AM |
The fragility of your argument | Dean Kent | 2007/05/14 08:16 AM |
The fragility of your argument | Linus Torvalds | 2007/05/14 10:57 AM |
The fragility of your argument | JasonB | 2007/05/14 03:48 PM |
The fragility of your argument | Dean Kent | 2007/05/14 06:36 PM |
The fragility of your argument | Ricardo B | 2007/05/16 01:40 AM |
The fragility of your argument | Dean Kent | 2007/05/16 02:32 AM |
The fragility of your argument | Ricardo B | 2007/05/16 05:41 AM |
PS | Ricardo B | 2007/05/16 05:50 AM |
The fragility of your argument | Dean Kent | 2007/05/16 08:07 AM |
Modern web browsing | S. Rao | 2007/05/16 08:16 AM |
Aha! | Dean Kent | 2007/05/16 08:27 AM |
Aha! | Dean Kent | 2007/05/16 08:32 AM |
Aha! | S. Rao | 2007/05/16 09:34 AM |
The fragility of your argument | Ricardo B | 2007/05/16 09:00 AM |
The fragility of your argument | Vincent Diepeveen | 2007/05/16 09:10 AM |
The fragility of your argument | Paul | 2007/05/16 02:01 PM |
The fragility of your argument | Vincent Diepeveen | 2007/05/17 02:05 AM |
The fragility of your argument | anon2 | 2007/05/15 12:35 AM |
Splits vs page allocations? | Matt Sayler | 2007/05/15 06:33 AM |
What's your point? | Michael S | 2007/05/13 07:55 AM |
What's your point? | anonymous | 2007/05/13 10:08 AM |
What's your point? | Michael S | 2007/05/13 10:31 AM |
let's stay with x86-64 for now, please | JasonB | 2007/05/13 06:16 AM |
x864 =) (NT) | some1 | 2007/05/15 02:03 AM |
Rock/Tukwila rumors | IntelUser2000 | 2007/05/06 01:27 PM |
Rock/Tukwila rumors | m | 2007/05/13 07:05 AM |
Rock/Tukwila rumors | mas | 2007/05/15 08:40 AM |