Given that Linus was once talking about the performance penalties of PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of interest:
http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
Yuhong Bao
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141665/direct/01/-
Yuhong Bao wrote:
> Given that Linus was once talking about the performance penalties of PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of interest:
> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
>
I find these tests mirror my own experience with PAE, the benefit of having the
nx hardware enabled justifies the few percent drop in performance I was able to
find.
I find the huge gain in web service hard to believe without a hint why a 64 bit
CPU would be 15x faster. The disk, memory, and network wouldn't be faster, and
the CPU intensive tests weren't significantly faster, so unless the systems were
tuned differently where's the gain? Same feeling about the TP test, an order of
magnitude faster on a test running the same application on the same hardware is
hard to buy without an explanation.
The only obvious source I can think of is running the test load at 100Mbit on
one test and Gbit on another, because I saw an early network driver do just that
in negotiations with a switch.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On 12/31/2009 04:49 AM, Bill Davidsen wrote:
> Yuhong Bao wrote:
>> Given that Linus was once talking about the performance penalties of PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of interest:
>> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
>>
> I find these tests mirror my own experience with PAE, the benefit of having the
> nx hardware enabled justifies the few percent drop in performance I was able to
> find.
>
> I find the huge gain in web service hard to believe without a hint why a 64 bit
> CPU would be 15x faster. The disk, memory, and network wouldn't be faster, and
> the CPU intensive tests weren't significantly faster, so unless the systems were
> tuned differently where's the gain? Same feeling about the TP test, an order of
> magnitude faster on a test running the same application on the same hardware is
> hard to buy without an explanation.
>
Why? simple, Memory. This system must have lots of memory (see the HIGHMEM64G) so
lots of IO must be bouncing on a 32bit system, where in 64bit it is copy-less.
Just my guess, but I'm not surprised.
> The only obvious source I can think of is running the test load at 100Mbit on
> one test and Gbit on another, because I saw an early network driver do just that
> in negotiations with a switch.
>
Boaz
Boaz Harrosh wrote:
> On 12/31/2009 04:49 AM, Bill Davidsen wrote:
>> Yuhong Bao wrote:
>>> Given that Linus was once talking about the performance penalties of PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of interest:
>>> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
>>>
>> I find these tests mirror my own experience with PAE, the benefit of having the
>> nx hardware enabled justifies the few percent drop in performance I was able to
>> find.
>>
>> I find the huge gain in web service hard to believe without a hint why a 64 bit
>> CPU would be 15x faster. The disk, memory, and network wouldn't be faster, and
>> the CPU intensive tests weren't significantly faster, so unless the systems were
>> tuned differently where's the gain? Same feeling about the TP test, an order of
>> magnitude faster on a test running the same application on the same hardware is
>> hard to buy without an explanation.
>>
>
> Why? simple, Memory. This system must have lots of memory (see the HIGHMEM64G) so
> lots of IO must be bouncing on a 32bit system, where in 64bit it is copy-less.
>
Did you miss the hardware configuration? It was run on a laptop with 4GB and two
little laptop drives. And there was no serious difference between the non-PAE
(sees 3GB) and PAE (sees 4GB) performance. Clearly there's little enough memory
to address in any mode.
> Just my guess, but I'm not surprised.
>
Eight thousand pages/sec out of a laptop with 5400 rpm drives doesn't surprise
you? Even if every page were copied to somewhere else the speed of the disk and
network are still 1000 times slower. I haven't found details on this "test" but
I'm guessing that the pages are all in memory so the disk is only used once,
maybe even the same page being read each time, and if the client is on the same
machine the "network" is loopback. Not representative of much of anything in the
general case, that.
>> The only obvious source I can think of is running the test load at 100Mbit on
>> one test and Gbit on another, because I saw an early network driver do just that
>> in negotiations with a switch.
>>
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On Thu, Dec 31, 2009 at 4:32 PM, Bill Davidsen <[email protected]> wrote:
> Boaz Harrosh wrote:
>>
>> On 12/31/2009 04:49 AM, Bill Davidsen wrote:
>>>
>>> Yuhong Bao wrote:
>>>>
>>>> Given that Linus was once talking about the performance penalties of PAE
>>>> and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of
>>>> interest:
>>>> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
>>>>
>>> I find these tests mirror my own experience with PAE, the benefit of
>>> having the nx hardware enabled justifies the few percent drop in performance
>>> I was able to find.
>>>
>>> I find the huge gain in web service hard to believe without a hint why a
>>> 64 bit CPU would be 15x faster. The disk, memory, and network wouldn't be
>>> faster, and the CPU intensive tests weren't significantly faster, so unless
>>> the systems were tuned differently where's the gain? Same feeling about the
>>> TP test, an order of magnitude faster on a test running the same application
>>> on the same hardware is hard to buy without an explanation.
>>>
>>
>> Why? simple, Memory. This system must have lots of memory (see the
>> HIGHMEM64G) so
>> lots of IO must be bouncing on a 32bit system, where in 64bit it is
>> copy-less.
>>
> Did you miss the hardware configuration? It was run on a laptop with 4GB and
> two little laptop drives. And there was no serious difference between the
> non-PAE (sees 3GB) and PAE (sees 4GB) performance. Clearly there's little
> enough memory to address in any mode.
>
>> Just my guess, but I'm not surprised.
>>
> Eight thousand pages/sec out of a laptop with 5400 rpm drives doesn't
> surprise you? Even if every page were copied to somewhere else the speed of
> the disk and network are still 1000 times slower. I haven't found details on
> this "test" but I'm guessing that the pages are all in memory so the disk is
> only used once, maybe even the same page being read each time, and if the
> client is on the same machine the "network" is loopback. Not representative
> of much of anything in the general case, that.
>
>>> The only obvious source I can think of is running the test load at
>>> 100Mbit on
>>> one test and Gbit on another, because I saw an early network driver do
>>> just that
>>> in negotiations with a switch.
>>>
>
>
> --
> Bill Davidsen <[email protected]>
> ?"We have more to fear from the bungling of the incompetent than from
> the machinations of the wicked." ?- from Slashdot
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
The article doesn't mention if a 64-bit kernel with 32-bit userland
was used or a 64-bit kernel with 64-bit userland.
Is there any performance benefit in having the former?
Regards,
Pedro
On Wed, 30 Dec 2009, Yuhong Bao wrote:
>
> Given that Linus was once talking about the performance penalties of PAE
> and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of
> interest:
> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
PAE has no negative impact on user-land loads (aside from a potentially
really _tiny_ effect from just bigger page tables), and obviously means
that you actually have more RAM available, so it can be a big win.
The "25% cost" is purely kernel-side work when the kernel needs to
kmap/kunmap - which it only needs to do when it touches highmem pages
itself directly. Which is pretty rare - but when it happens a lot, it's
extremely expensive.
The worst load I've ever seen (which was the 25%+ case) needed btrfs
and heavy meta-data workloads (ie things like file creates/deletes, or
uncached lookups), because btrfs puts all its radix trees in highmem pages
and thus needs to kmap/kunmap them all. So that's one way to see heavy
kmap/kunmap loads.
(In the meantime, I complained to the btrfs people about the CPU hogging
behavior, and afaik btrfs has improved since I did my kernel profiles of
the benchmarks, but I haven't re-done them)
Theres' a potential secondary issue: my test-bed for that btrfs setup was
a netbook using Intel Atom. The performance profile of an Atom chip is
pretty different from any of the better out-of-order CPU's.
Extra instructions cost a lot more. For example, out-of-order is
particularly good at handling "nonsense" instructions that aren't on a
critical path and aren't important for actual semantics - things like the
stack frame modifications etc are often almost "free" on out-of-order
CPU's because they only tend to have trivial dependencies that can be
worked around with things like the "stack engine" etc. So I seem to
remember that the "omit stack frame" option was a much bigger deal on Atom
than on a Core 2 Duo CPU, for example.
So it's entirely possible that the TLB flushing (and eventual misses, of
course) involved with kmap()/kunmap() is much more expensive on Atom than
it is on a Core2 system. So it's possible that my 25% cost thing was for
pretty much a pessimal situation, due to a combination of heavy kernel
loads (I used "git status" as one of the btrfs/atom benchmarks - pretty
much _all_ it does is pathname lookups and readdir) with btrfs and atom.
Linus
BTW, what do you think about the recent movement by distros toward installing PAE enabled kernels by default so that the NX bit can be enabled?
When MS enabled the NX bit in XP SP2, they had the advantage of being able to select the kernel in the bootloader (which was NTLDR) that was already being used for the /PAE switch in boot.ini. So when they added support for the NX bit, they were able to detect NX capablities in the bootloader and automatically select the PAE kernel. They still limited the physical address space to 4 GB in the non-enterprise/datacenter versions of Windows which before did not support more than 4 GB of RAM due to driver issues with things like DMA. Coincidentally around this time (which was around mid to late 2004), Linux 32-bit did it too with patches released to LKML around June 2004, and 2.6.8 incorporating the patch in August 2004, around the time XP SP2 was being released. But since Linux did not have that advantage, even after the distros moved to kernel 2.6.8, they still installed and used a non-PAE kernel by default, resulting in the NX bit not being used. Now, after 5 (!) years of this situation, last year Fedora and Ubuntu added that logic to their installer. Now they detect NX and automatically install a PAE kernel.
And yes there are CPUs with PAE and NX that has no 64-bit support. Intel was mostly to blame, with the most recent being the Atom N200 series that was very commonly used in netbooks (they only recently was succeeded with the Pine Trail Atoms being all 64-bit capable). Also was very common was the original Core Duo/Solo, as well as the late 533 MHz FSB Pentium Ms (the original one did not even support PAE at all!).? Also, there was the 5x0J Prescott Pentium 4 CPUs, which was common for a period too. But it wasn't only Intel, the first AMD Semprons from 2004 to late 2005 was another CPU that lacked the 64-bit but had the NX bit. And there was the Transmeta (which Linus used to work at, but left by the time it was released) Efficeon, which was the last CPUs released by Transmeta and lasted only a short time, and the VIA C7 CPUs (VIA eventually released a Nano which was 64-bit capable).
Yuhong Bao
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/171222985/direct/01/-
Hi,
> > Unfortunately Linux distros have not
> > properly promoted 64-bit kernels for 32-bit distros; although pure 64
> > bits is better, it would be a *helluva* lot better if people stuck on 32
> > bits for compatibility reasons had a saner alternative.
> >
> IIRC Fedora actually planned to offer that and dropped it. There seem to be
> display issues, I would assume the X stuff would have to match the kernel,
> although I'm basing that on reports. The only split I ever tried was text only.
>
Debian got a 64 bits kernel on the 32-bit distros. 2 years ago there where
display issue, but today it seems to works fine.
It is not the default kernel, but it is possible to use it.
But there is lot's of older cpu that doesn't support 64 bits, with more 1G of
RAM or that want NX support.
Matthieu
PS : there is even basic 64 bits library so you can run 64 bit application if
you want.
On 01/15/2010 10:53 PM, H. Peter Anvin wrote:
> On 01/15/2010 06:06 PM, Yuhong Bao wrote:
>>
>>> The big difference isn't between HIGHMEM4G (no PAE) and HIGHMEM64G
>>> (PAE), it's between HIGHMEM and !HIGHMEM. That cutoff is ~892 MB for a
>>> stock 32-bit kernel.
>> Unfortunately most desktop/laptop systems nowadays ship with more than 1GB.Luckily, in the case of Atom netbooks that Linus mentioned, most Atom netbooks ship with only 1GB of RAM, partly due to MS's restrictions.However, disabling HIGHMEM will turn off NX which all Atom CPUs have, unless you turn CONFIG_PAE back on.
>
> Since 32 bits means that any machine with 1 GB more means HIGHMEM, the
> number of non-embedded machines that should run 32-bit kernels today is
> functionally the null set. Unfortunately Linux distros have not
> properly promoted 64-bit kernels for 32-bit distros; although pure 64
> bits is better, it would be a *helluva* lot better if people stuck on 32
> bits for compatibility reasons had a saner alternative.
Unfortunately, the problem is, most of the Atom CPUs (except some of the
desktop ones, and the newest Pine Trail chips) don't support 64-bit,
which means there are a lot of new or almost-new machines that still
need a 32-bit kernel.
> There's a potential secondary issue: my test-bed for that btrfs setup was
> a netbook using Intel Atom. The performance profile of an Atom chip is
> pretty different from any of the better out-of-order CPU's.
>
> Extra instructions cost a lot more. For example, out-of-order is
> particularly good at handling "nonsense" instructions that aren't on a
> critical path and aren't important for actual semantics - things like the
> stack frame modifications etc are often almost "free" on out-of-order
> CPU's because they only tend to have trivial dependencies that can be
> worked around with things like the "stack engine" etc. So I seem to
> remember that the "omit stack frame" option was a much bigger deal on Atom
> than on a Core 2 Duo CPU, for example.
>
> So it's entirely possible that the TLB flushing (and eventual misses, of
> course) involved with kmap()/kunmap() is much more expensive on Atom than
> it is on a Core2 system. So it's possible that my 25% cost thing was for
> pretty much a pessimal situation, due to a combination of heavy kernel
> loads (I used "git status" as one of the btrfs/atom benchmarks - pretty
> much _all_ it does is pathname lookups and readdir) with btrfs and atom.
Luckily, most Atom netbooks currently only ship with 1GB of RAM (partly due to restrictions imposed by MS), and even Intel's Pine Trail Atoms is limited to only 2GB of RAM. And the desktop version has always supported 64-bit, and now all Pine Trail Atoms support 64-bit too.
Disabling HIGHMEM however of course will disable NX which all Atoms have, unless you turn CONFIG_PAE back on.
Yuhong Bao
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/196390709/direct/01/-
On 12/30/2009 05:29 PM, Yuhong Bao wrote:
>
> Given that Linus was once talking about the performance penalties of PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of interest:
> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
>
The big difference isn't between HIGHMEM4G (no PAE) and HIGHMEM64G
(PAE), it's between HIGHMEM and !HIGHMEM. That cutoff is ~892 MB for a
stock 32-bit kernel.
-hpa
> The big difference isn't between HIGHMEM4G (no PAE) and HIGHMEM64G
> (PAE), it's between HIGHMEM and !HIGHMEM. That cutoff is ~892 MB for a
> stock 32-bit kernel.
Unfortunately most desktop/laptop systems nowadays ship with more than 1GB.Luckily, in the case of Atom netbooks that Linus mentioned, most Atom netbooks ship with only 1GB of RAM, partly due to MS's restrictions.However, disabling HIGHMEM will turn off NX which all Atom CPUs have, unless you turn CONFIG_PAE back on.
Yuhong Bao
_________________________________________________________________
Hotmail: Trusted email with Microsoft?s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/196390706/direct/01/-
On Fri, 15 Jan 2010, Yuhong Bao wrote:
>
> Unfortunately most desktop/laptop systems nowadays ship with more than
> 1GB.Luckily, in the case of Atom netbooks that Linus mentioned, most
> Atom netbooks ship with only 1GB of RAM
Not the ones I have. If they had only 1GB of RAM when I got them, they got
upgraded.
Linus
>> Unfortunately most desktop/laptop systems nowadays ship with more than
>> 1GB.Luckily, in the case of Atom netbooks that Linus mentioned, most
>> Atom netbooks ship with only 1GB of RAM
>
> Not the ones I have. If they had only 1GB of RAM when I got them, they got
> upgraded.
That is why I said "ship with", I know that most netbooks can be upgraded to
2GB of RAM.
For most netbooks, that is the limit due to for one thing chipset limits,
even the new Atom N400 series has a 2GB limit in it's on-die memory
controller. At least it support 64-bit unlike the older N200 series without
the on-die northbridge.
Yuhong Bao
On 01/15/2010 06:06 PM, Yuhong Bao wrote:
>
>> The big difference isn't between HIGHMEM4G (no PAE) and HIGHMEM64G
>> (PAE), it's between HIGHMEM and !HIGHMEM. That cutoff is ~892 MB for a
>> stock 32-bit kernel.
> Unfortunately most desktop/laptop systems nowadays ship with more than 1GB.Luckily, in the case of Atom netbooks that Linus mentioned, most Atom netbooks ship with only 1GB of RAM, partly due to MS's restrictions.However, disabling HIGHMEM will turn off NX which all Atom CPUs have, unless you turn CONFIG_PAE back on.
Since 32 bits means that any machine with 1 GB more means HIGHMEM, the
number of non-embedded machines that should run 32-bit kernels today is
functionally the null set. Unfortunately Linux distros have not
properly promoted 64-bit kernels for 32-bit distros; although pure 64
bits is better, it would be a *helluva* lot better if people stuck on 32
bits for compatibility reasons had a saner alternative.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
> Since 32 bits means that any machine with 1 GB more means HIGHMEM, the
> number of non-embedded machines that should run 32-bit kernels today is
> functionally the null set.
You mean machines made today?
> Unfortunately Linux distros have not
> properly promoted 64-bit kernels for 32-bit distros; although pure 64
> bits is better, it would be a *helluva* lot better if people stuck on 32
> bits for compatibility reasons had a saner alternative.
Yep, I remember having to use --force-architecture to install the Linux
kernel from the 64-bit version of Ubuntu into the 32-bit version.
As I remember, the package name was the same as the 32-bit version, causing
confusion.
What led me to uninstall it, though, was that suspend/resume did not work
properly.
I am adding a CC to the Ubuntu kernel team mailing list.
Yuhong Bao
On Thu, Dec 31, 2009 at 02:29, Yuhong Bao <[email protected]> wrote:
> Given that Linus was once talking about the performance penalties of PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of interest:
> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
Does anyone have (links to) compile benchmarks? Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Jan 15, 2010 at 05:49:06PM -0800, H. Peter Anvin wrote:
> On 12/30/2009 05:29 PM, Yuhong Bao wrote:
> >
> > Given that Linus was once talking about the performance penalties of
> > PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by
> > Phoronix of interest:
> > http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
> >
>
> The big difference isn't between HIGHMEM4G (no PAE) and HIGHMEM64G
> (PAE), it's between HIGHMEM and !HIGHMEM. That cutoff is ~892 MB for a
> stock 32-bit kernel.
Thanks for the clarification - I had been wondering about why those
settings had been benchmarked against each other...
I took a mild interest because I have an EeePC 900 with 1G of RAM. The
machine can do PAE but my understanding is that this would lead to a
performance drop (I currently have VMSPLIT_3G so I can use all 1G of
memory) so I run it without HIGHMEM.
--
Sitsofe | http://sucs.org/~sits/
On Sat, 16 Jan 2010, Sitsofe Wheeler wrote:
> On Fri, Jan 15, 2010 at 05:49:06PM -0800, H. Peter Anvin wrote:
> > On 12/30/2009 05:29 PM, Yuhong Bao wrote:
> > >
> > > Given that Linus was once talking about the performance penalties of
> > > PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by
> > > Phoronix of interest:
> > > http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
> > >
> >
> > The big difference isn't between HIGHMEM4G (no PAE) and HIGHMEM64G
> > (PAE), it's between HIGHMEM and !HIGHMEM. That cutoff is ~892 MB
> > for a stock 32-bit kernel.
>
> Thanks for the clarification - I had been wondering about why those
> settings had been benchmarked against each other...
>
> I took a mild interest because I have an EeePC 900 with 1G of RAM.
> The machine can do PAE but my understanding is that this would lead
> to a performance drop (I currently have VMSPLIT_3G so I can use all
> 1G of memory) so I run it without HIGHMEM.
actually, it's 896M, not 892M, and i believe it's defined in
arch/x86/mm/init_32.c:
#define high_memory (-128UL << 20)
BUILD_BUG_ON(VMALLOC_START >= VMALLOC_END);
#undef high_memory
interesting that it's a hardcoded value -- is there reason that wasn't
configurable? (he asked from a position of total ignorance.)
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
On 01/16/2010 04:57 AM, Robert P. J. Day wrote:
>
> actually, it's 896M, not 892M, and i believe it's defined in
> arch/x86/mm/init_32.c:
>
You also lose an additional small chunk for the fixmap, in addition to
the vmalloc area.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
H. Peter Anvin wrote:
> On 01/15/2010 06:06 PM, Yuhong Bao wrote:
>>> The big difference isn't between HIGHMEM4G (no PAE) and HIGHMEM64G
>>> (PAE), it's between HIGHMEM and !HIGHMEM. That cutoff is ~892 MB for a
>>> stock 32-bit kernel.
>> Unfortunately most desktop/laptop systems nowadays ship with more than 1GB.Luckily, in the case of Atom netbooks that Linus mentioned, most Atom netbooks ship with only 1GB of RAM, partly due to MS's restrictions.However, disabling HIGHMEM will turn off NX which all Atom CPUs have, unless you turn CONFIG_PAE back on.
>
> Since 32 bits means that any machine with 1 GB more means HIGHMEM, the
> number of non-embedded machines that should run 32-bit kernels today is
> functionally the null set. Unfortunately Linux distros have not
> properly promoted 64-bit kernels for 32-bit distros; although pure 64
> bits is better, it would be a *helluva* lot better if people stuck on 32
> bits for compatibility reasons had a saner alternative.
>
IIRC Fedora actually planned to offer that and dropped it. There seem to be
display issues, I would assume the X stuff would have to match the kernel,
although I'm basing that on reports. The only split I ever tried was text only.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
>> Given that Linus was once talking about the performance penalties of PAE and HIGHMEM64G, perhaps you'd find these benchmarks done by Phoronix of interest:
>> http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae
>>
>
> The big difference isn't between HIGHMEM4G (no PAE) and HIGHMEM64G
> (PAE), it's between HIGHMEM and !HIGHMEM. That cutoff is ~892 MB for a
> stock 32-bit kernel.
BTW, Linus posted this about HIGHMEM and PAE:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=78966&threadid=78766&roomid=2
A few corrections though. HIMEM.SYS was never about memory windowing, EMS was.
The way the 286 could access 16MB of memory was plain old segmentation, just in a different way than EMS did.
And the main issue with PAE in Windows was driver issues, I think, which is why when they enabled PAE to get the NX bit, they limited physical address space to 32-bit on client versions of Windows.
Yuhong Bao
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/-
> The way the 286 could access 16MB of memory was plain old segmentation, just in a different way than EMS did.
I mean different from the way 8086/8088 did, which was that the selector's base address was always the selector value itself shifted by 4 bit to get a 20-bit base address. The 286 and later supported this in their real mode (and virtual 8086 mode in 386 and later) for compatibility. But in their protected mode, the selector was looked up in the GDT/LDT to get the base address and length of the segment as well as protection attributes.
Yuhong Bao
_________________________________________________________________
Hotmail: Trusted email with Microsoft?s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/-