OSDev.org

I've search something but i don't found this question in the forum the answer on this question.
Is better use 4kb paging or 4mb paging?
with the 4mb paging, i can use less memory to know if a page is used or no (of course, there are less page..) and maybe it could be easier to implement.. but with the 4mb page there's could be more internal fragmentation but nowadays the program is bigger so maybe this problem is less important..

and a second question..it's a stupid idea to map all the memory for the kernel, so i can access every memory, so i can cloning process page without desable the paging?

i hope that you can understand my bad bad english..

Srowen wrote:I've search something but i don't found this question in the forum the answer on this question.
Is better use 4kb paging or 4mb paging?
with the 4mb paging, i can use less memory to know if a page is used or no (of course, there are less page..) and maybe it could be easier to implement.. but with the 4mb page there's could be more internal fragmentation but nowadays the program is bigger so maybe this problem is less important..

It depends on the situation, but in most cases, 4KB paging is usually better. The amount of space needed to store paging information is tiny compared to the pages you allocate, so it is not much of an issue. 4MB pages are much faster to allocate, but unless you use a 4MB contiguous block, you are probably going to waste a lot of memory. It is probably best to implement 4KB pages only at first, then add 4MB page support later if you need memory allocation to be faster.

Srowen wrote:and a second question..it's a stupid idea to map all the memory for the kernel, so i can access every memory, so i can cloning process page without desable the paging?

I think what you are asking is if it is a good idea to have the kernel mapped in every address space. That is definitely true, because once you get to enabling interrupts, you need the kernel to be in the current address space *all the time*, otherwise the computer will triple fault and reset. You also should be able to clone processes without disabling paging, by reserving a piece of address space to temporarily map a frame you are going to use for the new process and copying the data there.

perfect.. and so the last stupid question.. when an interrupt come i should switch to the page directory of the kernel? first i push the CR3 in the stack and then i change it.. this is correct? but so i have to save the kernel directory somewhere it is accessible to the other process.. or maybe i stop the paging, load the addres of the kernel directory and then restart paging.. i don't undestand very well this think..

Srowen wrote:perfect.. and so the last stupid question.. when an interrupt come i should switch to the page directory of the kernel? first i push the CR3 in the stack and then i change it.. this is correct? but so i have to save the kernel directory somewhere it is accessible to the other process.. or maybe i stop the paging, load the addres of the kernel directory and then restart paging.. i don't undestand very well this think..

When an interrupt happens, CR3 is pushed. That is correct. Then if you need to switch tasks the CR3 is changed, or else its just left alone.

All of your applications page directories should have the kernel mapped in also so that your kernel won't need to change page directories to work.

Generally, you'd want to limit use of 4MB pages, if any, to specialized purposes that can be optimized by using large contiguous mappings, typically for large-memory systems and/or large applications. For your general page pool, you probably want to stick to 4KB pages.

Most OSes can get along perfectly fine without using any 4MB pages.

A few typical examples of 4MB page optimizations:

1) A kernel that chooses to maintain a one-to-one mapping to physical memory (for example, for software access to DMA buffers).

2) A large database server with a big preallocated shared memory area for its buffer cache & shared state between its processes.

3) Mappings for driver access to on-board device memory, if that memory is large enough.

If you limit use of large pages to non-pageable memory (as you could for all the above examples), then paging code doesn't need to handle multiple page sizes.

On the other hand, memory is cheap and you already fill up 4MB if you have a screen-sized bitmap...

Yeah, but not "allocate 4 MB to ls" kind of cheap. If the linux devs thought that way, my system would be using at least 320 MB (out of 1024) just to have all the processes that currently exist in memory.

Combuster wrote:On the other hand, memory is cheap and you already fill up 4MB if you have a screen-sized bitmap...

But keep in mind that it's not just about physical memory usage. (It's true that as memory gets more plentiful a larger allocation size will make sense--though 4KB to 4MB in one jump would be extreme.)

It's also about the granularity of paging. If a process touches 100 bytes of a paged-out 4MB page, that's a whole lot more I/O to bring that page back into memory--the rest of which might never get used--than it would be for a 4KB page. (You might want to prefetch a bit extra anyway, as indicated by working-set modeling, but again, 4KB to 4MB is a big jump. You can instead implement "page-ahead" by bringing in a much smaller number of 4K pages.)

can't i use an hybrid solution, with 4MB pages and if i have a small process like 'ls' i reserved some 4Mb pages to them (for example 2 pages of 4Mb for small process) and then i use a pagination of 4kb only for this pages to address them and the segmentation to protect their address space?

Srowen wrote:can't i use an hybrid solution, with 4MB pages and if i have a small process like 'ls' i reserved some 4Mb pages to them (for example 2 pages of 4Mb for small process) and then i use a pagination of 4kb only for this pages to address them and the segmentation to protect their address space?

Well, yeah, but that's harder than it sounds, and harder than just using 4KB pages. Use of 4MB pages along with 4KB pages in a prototype or first release is imho on the border of premature optimization. Use of them alone causes huge memory problems with lots of small processes. Whether they're worthwhile in the end or not is a different issue.

What you can do, is to start the heap say, 1MB under a 4M boundary, and then start mapping 4M pages whenever you can (i.e. when the process crosses 1M heap and therefore already requires a significant fraction of that amount.)

Its still a heuristic, which are meant to never be perfect, but you get a better memory-TLB use ratio that way.