Recommendations...

Michael ODonnell michael.odonnell at comcast.net
Wed Jun 16 09:20:39 EDT 2010



> Processes can potentially indirectly access more than 4 GiB of RAM
> by using memory windowing/bank swapping/etc.  This would be similar
> to "Expanded Memory" from the days of the 8086.  Reserve some
> range of process-addressable memory.  A special library/system
> call exchanges that block of memory with another block from the
> not-directly-addressable RAM.

(cringe!)  I hope you're not speaking from recent experience.  I'll
give you a dollar if you can show me such a system.  ;->  Actually,
that'd be a bargain price entrance-fee to view such a museum piece!


>> IIRC, PAE is not necessary until you want to address *more* than
>> 4Gb of RAM, though I have a nagging, fragmentary memory that some
>> other issue (maybe related to PCI mappings or other I/O stuff?)
>> can make PAE advisable even when you don't have more than 4Gb.
> [...]
> The physical address space is used for any memory-mapped hardware.
> That includes RAM, but can also include PCI configuration space,
> option ROMs, video RAM, AGP aperture, etc.  All of the latter eat
> up physical address space.

Duh, yes - that's what I was thinking of.


>> There used to be a config option that made a full 4GB of virtual
>> address space available to every process by forcing the kernel to use
>> its own page tables; support for this capability has been deprecated,
>> apparently based on the attitude that anybody who wants more than
>> 3Gb virtual address space should be running a 64bit OS, a rather
>> condescending stance IMO.
>
> It may be condescending, but it also strikes me as realistic,
> especially given all the gyrations the kernel must have to go
> through to support it.  Why *would* you want to run a 32-bit kernel
> if you're trying to do large memory stuff?

Well, when you've got an installed base of venerable yet cantankerous
32bit apps that are tuned for that 4Gb virtual space and need to
interoperate with a bunch of 3rd party apps and libs and drivers that are
also 32bit and it would be a bitch to port them to 64bit and requalify
them all over again and oh yeah they're running on 32bit machines that
have plenty of life in them and all you wanted was to get the benefits
of running a newer kernel but now that feature you were using has been
discontinued....  that's one scenario.  Guess how I know.  >-/
 


More information about the gnhlug-discuss mailing list