OSDev.org

Freanan wrote: Is there any way to align it in C?

In general, I agree to Solar. But for the case you need aligning in C in the future: GCC offers an attribute for that. IIRC,
__attribute__((align(4096)))
should do the job for page aligned data, otherwise just change the count. Haven't tried that however, I just read it! ::)

EDIT: Have a look at http://www.ohse.de/uwe/articles/gcc-attributes.html for an overview of attributes.
cheers Joe

That solved it!
Thank you ;D !

Btw... if i add ALIGN 4096 to my assembler-file, this means that the space that is missing until the next n*4096 mark is filled with zero?
I think this is not very nice, since it wastes space... Is there any other way to do this (other then just using a hardcoded adress - i do not like that approach, because i prefer to have those things as "safe" arrays that are embedded somewher and that are not going to be overwritten)?

That's what the physical memory manager is for, you just ask it for an unused page, make it into a page directory, get another one, make it into a page table, then enable paging.

OK, thanks...
So i should set up a physical memory manager before i start paging.
I am really eager to do this, as i think i have now properly understood all the concepts of memory management.
But i have one last question:
If i use a stack for physical memory management, is there any "policy" or fixed number that most kernels use, how much space to reserve for this stack?
Or is the physical memory management stack a dynamically growing data structure like a c++ stack class (i would be confused in this case, as this would already require proper managment, so it would be a chicken and egg scenario)?

Hi!

Freanan wrote: But i have one last question:
If i use a stack for physical memory management, is there any "policy" or fixed number that most kernels use, how much space to reserve for this stack?

It depends on how much physical memory you want to support, the best is probably to check for the amount of physical memory installed, then calculate the space needed for the stack and treat this memory as allocated (so when you initialize the stack, don't put these addresses in). Don't allocate this memory in the global space. However, for 4 GB you'd need 4MB of space for the stack (assuming you put in 32-bit addresses for the free pages), so it isn't that critical anyway. For now, I use a bitmap in my physical memory manager (it takes only 1024 byte for the 32MB of memory i currently support, but I'll probably switch to a stack as soon as I break this border)

And, no, it's probably not possible to dynamically change the size of the page stack, since that would need a high level memory manager working .

cheers Joe

The usefulness of the page stack is that when all pages of memory are used, the stack is empty (so can be recycled itself). As JoeKayzA said though this will require finding a 4MB lump of contiguous physical memory until paging is enabled (if the user has 4GB RAM that is), for this process I recommend a secondary manager only used during the init process using the memory map method I mentioned. Once paging is on you can then freely swap in/out pages.

The easiest way to build this would be to have something like PageStack::Initalise(classHasFree *PagingManager, memmap_t *MemMap); - "classHasFree" is just a pure virtual base class declaring the "Freepage" function (if you're in C then just use a function pointer). During the initalization phase the pointer would be NULL, the stack would check whether it is NULL before calling it.

If you are using a double part kernel (2 chunks, an init that is removed later and the kernel proper) then you can just use the memory map based allocator in the init part which prepares the environment for the page stack handler (and enables paging, etc) so that the kernel proper doesn't need to be modal.

OK, thanks..
So i can use a maybe ineffieciently large pagestack before paging is enabled, and switch to a fragmented, probably smaller page stack afterwards...

Maybe it would also be good to have a double-layered physical memory manager with one stack for page tables (or physical page-table-frames ie 1024*4096 byte long pieces oh physical memory) and separate page stacks for each table, that can be created and deleted on demand (when whole tables are freed or allocated)?
With all memory freed that would increase the size of space that is wasted for the stacks by only 1024 dwords while when much memory is allocated, whole page-stacks can be deleted (saving much space - if my calculation is right).
Is this scheme used by any OS? And if not, have i forgotten something negative about it?

Hi,

Freanan wrote:Maybe it would also be good to have a double-layered physical memory manager with one stack for page tables (or physical page-table-frames ie 1024*4096 byte long pieces oh physical memory) and separate page stacks for each table, that can be created and deleted on demand (when whole tables are freed or allocated)?
With all memory freed that would increase the size of space that is wasted for the stacks by only 1024 dwords while when much memory is allocated, whole page-stacks can be deleted (saving much space - if my calculation is right).
Is this scheme used by any OS? And if not, have i forgotten something negative about it?

I considered something similar, but in the end chose not to worry about it. The problem is that swap space, memory mapped files and allocation on demand becomes in-efficient for 4 MB (or 3 MB) pages, so over time you end up splitting all of the large pages into smaller 4 KB pages.

This by itself isn't a problem. The problem is that you can't easily combine 4 KB pages back into a single 2/4 MB page. Without "large page recombining", over time large pages become split into 4 KB pages and stay that way and you end up using nothing but 4 KB pages anyway. IMHO this makes supporting 4/2 MB pages seem futile unless you can efficiently recombine them.

So, the first question I'd have is, how are you going to do this "large page recombining" and how much overhead would it involve?


Cheers,

Brendan

I see the problem, if this is what you meant...
When memory is allocated in the beginning, we can chose to first give away memory that is part of a already partly used "large page" instead of fragmenting new large-pages...
But when pageframes are freed, we cannot free memory in a economic way (ie freeing it so that we can free a whole large-page as fast as possible), as the adresses to free come to us by the client. Thus memory will end up fragmented to small pages.
Still.. when pages are re-allocated we can chose to first give away the pageframes associated with already partly used large-pages to get back the adantage..
So in the long run i still think it makes sense.. but maybe this is wrong...

I am sorry if this post is quite confuse... The double-layered memory idea was really just "some thougt and i had to come up with the details on the fly while writing the post...
I might also elaborate on the idea in general (as i only outlined it in my last post), if there were or are misunderstandings..

Hi,

There are a number of things that cause a large page to be broken into smaller pages - sending them to swap, allocating a small page when you've only got large pages free, when the application frees some pages (but not the entire large page), etc.

So if (for various reasons) the large pages are continually being broken into 4 KB pages, and if there's nothing to recombine them, eventually you'll be left with 4 KB pages and nothing else.

Allocating 4 KB pages before breaking up a large page helps. Having a swap that can store large pages and 4 KB pages would also help and so would supporting memory mapped files in 4 MB blocks (although holding things up while 4 MB is transfered to/from disk might not be so good). Asking applications programmers to "tune" their applications so that the application is less likely to break large pages up could also help.

Even if you do all of these things you'd still end up with the large pages broken down into 4 KB pages eventually, as some applications won't (or can't) use whole large pages effeciently, or you'll need a 4 KB page when none are free, etc. By doing all of the these things it would just take longer.

For example, imagine the computer has 128 MB of RAM (or 32 large pages) and the OS has no choice but to split one large page up every 10 minutes (on average). After about 5 hours you're not using large pages anymore. This isn't a very realistic example - it's likely that half of them will be split up during (or just after) boot, and you might have a server (or the kernel) that runs forever and uses a few large pages, so that after 2 hours you've got 2 whole large pages in use and none free, and after 3 days you've still got 2 whole large pages in use and none free.

Of course this also depends on what software you're running and how they use memory, if your pager allows 4 MB to be transferred to/from disk and how long your OS is running for - if your OS needs to be rebooted every 5 minutes you don't need to worry, but if it's running as a server and only ever rebooted when the kernel is updated (twice a year?) then it's more of a concern.


Cheers,

Brendan

I think there is something to recombine them...
Every small page is constantly associated with a lage page (to which it belongs).
When a virtual page is swapped back in, a physical page is allocated again and the OS can chose to give away a physical page that belongs to a partly used large page.
Thus the large pages that are partly in use, will be used up more and more when memory is allocated, and everytime a large page is full we can delete its page stack as well as its entry in the large-page-stack...

Problems would occur, if not enough new memory is allocated to use up the fragmented large pages completely or if things are only swapped out and not back in.
And yes, memory mapped files and dma and so on would fragment the large pages, but are such things used enough to make it all inefficient?

I'm confused, are you talking about using "Page Size Extensions" (PSE) or "Page Colours"? Page Colours are where the memory is divided into units (of the same size as the CPU's cache) to maximize the CPU's ability to store as much as possible in the cache.

That or you're confused by how paging works, the physical addresses in page tables can point all over the place, you can have a page at the very start of physical memory (0x0) then the next entry being at the end of memory (say 0xBFFFF000 with 3GB RAM), it is not necessary to always associate a certain 4MB window with a given page table.

PSE will generally break down in that over time the large pages will need to be broken up for smaller uses, eventually all large pages will be broken up and scattered between various processes so won't be reclaimable.

I am talking about neither of them (although page colours sound interresting).
I was talking about the physical memory manager only. I know that the pointers in the page-tables can point anywhere, but what i was thinking about was applying the same table-pages hierarchy that the virtual pages use to the physical memory manager, so that there is not just a pageframe-stack, but one pagetableframe-stack with a seperate pageframe-stack for each entry. The client would still only be able to allocate normal 4k pages, but the physical-mm internal structure would be double-layered.
In this kind of physical memory manager i would associate the single pageframes constantly to the pagetableframes they are in.

Hi,

Freanan wrote:I am talking about neither of them (although page colours sound interresting).

Ok, now I'm confused - I thought you were talking of 2 seperate free page stacks, one for 4 KB pages and the other for 4 MB pages (for PSE).


Cheers,

Brendan

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 don't understand it.