OSDev.org

Have I missed it, or it didn't really come out, but what's the use of 4MB physical pages? The only use I can see is PSE, but to support high memory, isn't it easier and more powerful to redesign the virtual memory manager to support PAE anyway? PSE needs modifications to both the physical and the virtual mem manager (I read somewhere that it's more straightforward to handle, but I don't think this is true), and as Brendan said, 4MB pages are a pain when it comes to copying, locking, swapping etc...

You probably won't experience any performance boost on using 4MB pages too, so why support them? (just because they are there? Most of us don't use segmentation too..)
So, ???

cheers Joe

Stack level 1 is like a stack equivalent of the page-directory:
It consists of pointers to 2nd level stacks which are like the equivalent to the page-tables, consisting of the adresses or numbers of the pages that lie in the memory area associated with the entries in the 1st level stack.

AR wrote: By the sounds of this, not meaning to be rude, but I don't think it will accomplish anything (except making the manager slower), but I admit that I really understand it.

Normally it does not have to acomplish anything, but it would enable us to omit whole 2nd-level-pageframe-stacks, as long as they are completely free or completely used up.
If the whole 2nd-level stack is free, that could be marked in the corresponding entry in the 1st level stack and the second level stack does not need to exist, as we know then that all pages that are associated with it are also free.
The same thing when it is all in use... Then the 1st level entry would not exist in the 1st level stack and the 2nd level stack would not need to exist either, all pages being used.
Only when one of the "large pages" is partly used up a stack would be needed to tell which parts are used and which can be given to the client.

Sorry about the misunderstandings!

JoeKayzA wrote: Have I missed it, or it didn't really come out, but what's the use of 4MB physical pages?

The main reason I think is for pages that are shared between all addresses spaces and are never paged out -- like the kernel itself. Using a single 4MB page for the kernel means that it will consume only one PTE in the TLB, which reduces TLB thrashing.

JoeKayzA wrote:PSE needs modifications to both the physical and the virtual mem manager (I read somewhere that it's more straightforward to handle, but I don't think this is true)

Some people believe it's easier to support because there are no page tables (they seem to like it as an easy escape from having to understand paging properly ), if you use PSE for the kernel (which is most likely physically contiguous) then it will make the memory accesses to it slightly faster, although insignificantly as far as I can see.

@Freenan: Okay, I think I can understand it now. I'm sorry but I don't think it will offer any benefits. As the pages become free there is plenty more memory to put the stack into, but as the pages get used, the stack automatically becomes smaller as entries are removed, when all pages are used the stack no longer exists. It would be slower to perform 2 lookups rather than just poping from the free stack. Can you explain what special feature this provides that the existing approaches don't have?

Colonel Kernel wrote:

JoeKayzA wrote: Have I missed it, or it didn't really come out, but what's the use of 4MB physical pages?

The main reason I think is for pages that are shared between all addresses spaces and are never paged out -- like the kernel itself. Using a single 4MB page for the kernel means that it will consume only one PTE in the TLB, which reduces TLB thrashing.

Who has introduced the paradigm that kernel space must all be non-pageable? When kernel code is used frequently, it won't get paged out anyway, only some code (paging code , interrupt handling...) must not be paged out, IMHO.

I didn't know that 4MB pages only need one single Tlb line, are you sure about that?

cheers
Joe

It depends on your design, most people here seem to be developing microkernels, microkernels hardly have anything other than the stuff that can't be paged out making it redundant to support that. If you are writing a monolithic kernel then there is more of a necessity (everything in a microkernel will probably be used multiple times a second but there may be large areas of the monolithic kernel that are rarely used, and the kernel image itself will be relatively large).

The TLB line thing is correct IIRC (the page directory entry points directly to a contiguous physical 4MB of RAM).

AR wrote: It depends on your design, most people here seem to be developing microkernels, microkernels hardly have anything other than the stuff that can't be paged out making it redundant to support that.

Back to the 4MB-page issue then, wouldn't a microkernel be smaller than 4MB anyway (along with data)? So you would end up using one PSE page, for the kernel. The pagetable access pages, which can take up much more virtual space, won't be contiguous anyway...

Or did I miss something in microkernels that takes up much more physical space?

cheers Joe

No, a microkernel will be quite small (why it's called micro ), it is highly unlikely that you could fill the whole 4MB (Even Linux is smaller than that IIRC), but if you just imagine the unused space as preallocated kernel heap then there won't be anything wasted.

The kernel is about the only special case where 4MB pages are useful though, the entropy problem Brendan was talking about removes the usefulness for anything else.

AR wrote: @Freenan: Okay, I think I can understand it now. I'm sorry but I don't think it will offer any benefits. As the pages become free there is plenty more memory to put the stack into, but as the pages get used, the stack automatically becomes smaller as entries are removed, when all pages are used the stack no longer exists. It would be slower to perform 2 lookups rather than just poping from the free stack. Can you explain what special feature this provides that the existing approaches don't have?

No problem - it was just an idea anyway
There are no further special features than that of saving memory by deleting some of the sub-stacks - but after your post that seems to be ruled out, so yes - there is no benefit in the idea.
I only had problems to imagine how to delete parts of the stack and how it could vanish when it is empty.
But i think i understand now - one can just create a new starting adress for the stack in the first page that is freed, after the stack was deleted...(?)
And that parts of the stack that use whole seperate pageframes can be deleted everytime they become free(?).

This has to do with paging; the page stack would always be in a certain reserved virtual range, but the physical memory behind those virtual pages can be removed once the page is no longer needed and then used for something else. You will want to keep a buffer page (the page after the last one that is currently needed) to prevent continually reallocating that page when one more is pushed then popped.

About "deleteing parts of the stack", the design doesn't permit that but you prevent it from becoming a problem by not pushing the reserved pages to begin with (When you generate the stack during the kernel init, simply don't push any of the pages that are used by the kernel, or are reserved in the memory, etc).

JoeKayzA wrote: Back to the 4MB-page issue then, wouldn't a microkernel be smaller than 4MB anyway (along with data)?

You'd have to be pretty talented to get it all to fit in under 4KB, though. Better one TLB entry than many, IMO.