OSDev.org

How important are 4MiB pages today? Are they used in Windoze and Linux? And does anyone else use 4MiB pages in his/her OS? I?m asking, because if I wouldn?t implement 4MiB pages, my physical mem manager could be some times faster!

The pros of 4meg pages:
+ 1 tlb entry vs. 1024 entries when using 4kb pages.
+ there is a separate tlb cache for 4m and 4kb pages. (-> more pages can be tlb-cached when you mix 4k and 4m usage)

FlashBurn wrote: How important are 4MiB pages today? Are they used in Windoze and Linux?

I've seen a third party HAL for Windows a few years ago, which enabled 4m paging. They did some benchmarking and said it's much faster.

And does anyone else use 4MiB pages in his/her OS?

Hmm I planned to. But it's currently only supported by an additional page defragmentation and merging thread (in my design specs, I haven't implemented a pager thread yet..).
If someone knows how to implement a nice algorithm which makes defragmentation and merging unneccessary, please post..

I?m asking, because if I wouldn?t implement 4MiB pages, my physical mem manager could be some times faster!

Yep but overall memory access performance would be slower than with 4m pages enabled.

I use 4 MB pages in my kernel. A user application can either request 4 KB or 4 MB pages. I use this feature in the libc library which requests multiples of 4MB from the kernel and then splits it for the smaller malloc calls on request.

I find it faster this way and more efficient. There's only 1 system call, a fast page table allocation, and then the rest is userspace.

However, a drawback I've found is that I can't use this method on old CPU's (386, etc..) which means I can't use any of those cool embedded Intel compatible boards unless they're P2 and upwards.

Also, bochs, qemu, whatever don't do 4MB pages well (last time I checked) so I have stopped using emulators to test my kernel. vmware seems to give the least problems.

@durand

Maybe you can tell me what you use to organize the free and used pages. I use bitmaps, but I?m looking for a faster way to do it!

I also use bitmaps ( slow, I know ).

My memory bitmap is split into 4 KB sections. The good thing about 4MB pages is that the 4MB needs to be contiguous space. So, I just search for 1024 free, contiguous pages and I allocate those to the new 4MB page.

To speed things up, I store the position of the last allocated section. My next search in the bitmap starts immediately after the previous allocation. This almost guarantees an immediate match on free space. (unless the system has been up a long time with programs with long uptime.) When the end of the bitmap is reached, it just wraps around and starts searching again.

Presumably, the apps which used the beginning of the memory map have released their memory already.

Also, whenever an app free's memory, I jump back to the newly free'd position.


It's not great, I know, but it's good enough at the moment, appears to be pretty fast, and is easy.

There are somethings how you could speed up the bitmaps somemore - I think so, means I?m not sure -

I have a bitmap for the 4KiB pages, for the 4MiB pages and 1 bitmap for the 4MiB pages where is min 1 free 4KiB page.

I have the number of the first free 4KiB page and the first free 4MiB page.

When I allocated a 4KiB/4Mib page I search for a new free page and save the number.

When I dealloc a 4KiB/4MiB page I look if the page number is smaller than the number I saved.

Have you written the code in C or ASM? Maybe we could look at eachothers code?!

sure... here's all my source: http://www.djm.co.za/spoon/

OK, I?m not as far as you but I pefere my version to alloc and dealloc! Here is the source.

Cool. I see what you mean by the seperate bitmaps now. It would definitely be faster. Thanks!