Hi guys,

Just interested if anyone is using a page size other than 4KByte? Since most apps seem to be quite large (data wise) and most PC's having at least 512MB of RAM installed, and with the limited TLB size, would it start making sense to start making more use of the larger page sizes?

Admittedly a basic app would need 3x pages (one for code (R-X), one of data (RW-) and another for stack (RW-)), which means up to 12MB allocated (or for 64bit long mode, 6MB allocated, since long mode only offers 4K or 2MB pages).

While I can see that as a significant downside (less granular memory), the upside is that there will be less strain on the TLB and make memory allocation more efficient when slab allocators are being used (since they are the most common), since you're modifying the page tables less often.

I don't see swapping pages to/from disk as being a problem, as most drives like long streams of data (2/4MB) over small chunks (eg 4K).

It just seems that most people are sticking with 4K pages due to popular convention and/or the abundance of tutorials that only reference using 4K pages?

Thought or comments appreciated?

PS.
R-X - Readonly, Execute
RW- - Read/Write, No execute.

I've been wondering the same myself.

I'd probably stick to 4k pages for normal .code/.data though, since those sections tend to be _relatively_ small - well below 2mb (or even 4mb) for most apps. But for heap allocation, 4meg pages would be nice.

Haven't played at this system level for quite some years, though. Dunno if NT uses large pages anywhere?

I think it comes down to the efficency of the MCB chain, at least in DOS.
I cant eleberate more on the executive level code though

How about adjustable sizes? You can have an "Advanced [OS Name] Setup Menu" and then submenus to select page sizes of 512 bytes/1K/2K/4K/8K/16K/32K/64K/128K/256K/512K/1M/ETC.


Personally, I would use no less than 512 bytes, but no more than 1M.

Adam: not doable, we're talking hardware page size here. Page sizes of less than 4kb would require way too much management overhead...

What I think the reason is:

Loading a large page from HDD to RAM for only one short access would take too long.
So if the pages are small you have to read unused ones from HDD very often when executing long code sequences.
If the pages are very long you have to load the whole page from HDD even if you need only one byte(as data or so).
Just try to find a good value in between of both.

OK... hang on.. if it is hardware pages here, then (correct me if I'm wrong) 32-bit x86 CPUs have a page size of 4K, where as x86-64 CPUs have a page size of 8K.

Adam: the 80386 introduced proper protected mode (unlike the 80286 hacky shit) with paging - with a fixed size of 4k pages.

Later on 2meg and 4meg pages were introduced, can't remember which was implemented first and where, but a good bet would be that the ppro introduced it.

Google instead of making assumptions.

according to intels manual
Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Volume 3A:
System Programming Guide, Part 1

Thanks for looking it up, Gizmo

If your operating system uses the PAE flag to get 34 gb of ram and you wanted to allow greater than 4gb of ram access to your user mode aps, you would have to setup segmentation?

(It says you get 36 bit addresses in your page table, but from what I read your logical addresses are still the same.)

How would you make a c api for apps to use it, make some function call that allocates a size in any upper segment not full yet, then you can copy to and from this address using similar function calls with a handle?
(to avoid a non-standard malloc, apps simply open a handle to the upper segment address space, and they can either feed a low segment address to copy memory back and forth or use a mapping method)
(could be useful for databases that can fetch the data store it locally and then save changes made to local copy, but would be real slow for real time graphics because of the extra allocating and copying)

For 32bit systems, you'd need something like the "address windows extensions" in Windows... basically you map/unmap views of the extended memory range, kinda like if you use memory mapped files to access huge files.

So >4gig ram 32bit systems would be useful for either for software that's able to handle this kind of mapping (I think MS SQL server is?), or systems where you need lots of memory but not necessarily for one single app... ie., a terminal server running lots of users with standard apps.