OSDev.org

When I started turning kernel to support paging I had an idea.
Run kernel with disabling paging, while user applications enable paging. This will reserve benefits of paging and reduce time of mapping in kernel mode. Why not?
;D

Well i think that all memory management functions in the IA-32 architecture are managed by processes that have priviledge level 0 or so.(i'm not sure about this though) I mean you'll have some security issues. Cause if you are using protection and have assigned the user processes cpl=3 i don't think the processor will let you modify the control registers. Of course you could assign all processes cpl=0 and have only one protection ring but thats not a good tactic.

the big question is "does setting CR0.PG also flush the TLBs" ? if it does, that will be a performance killer.

Also think at a system call that passes a string argument (that is, a userland pointer) to the kernel. how will you translate that argument into a physical address ? and what if the string spans over 3 pages (write buffer, for instance) ?

And moreover, machines with +4GB RAM will need paging to access high memory.

So what was the advantage, again ?

Isn't it also possible to access over 4gb of memory using multiple segments each one of 4gib size? (not overlapping)

how will you translate that argument into a physical address ?

This can be done exactly as processor does. But is it more efficient than mapping and flushing TLB may be?? but I think in that way the kernel will take control over all memory directly.

Well I am not sure. I read before that processor under real mode is excuting faster than protected mode. And by the way I think that fetching page dirs and tables may be slower than segmented mode. ???

ces_mohab wrote: Well I am not sure. I read before that processor under real mode is excuting faster than protected mode.

That was certainly true for the 386, and indeed you have performance penalty from reading missing page entries. But then, with pentium and the like, you have "4MB pages" that can even be made global (never flushed implicitly). With one or two such page, you could map your whole kernel & relatives and run code there with virtually no performance penalty against good-old real mode.

Oh, except from caching effets, of course. Since real mode has only 1MB of RAM, you're more likely to fit all your code in L2 cache than you are with a 4GB environment

Hmm, but just simply flicking the CR0.PG switch doesn't mean your in real mode. My current design runs in non paging protected mode, but facility of paging will be supported for user land somehow. I gave this a thought awhile back and decided to use segmentation for user land as well, so no paging is ever used but only when software requires it. However this leads to bigger GDTs and or LDT per process which now I'm not even sure if it is going to be any better then paging. But then the design is around the whole idea of never paging out memory which is a topic on its own.

Okay back on topic, I think you need to decide whether as a whole OS if paging is even required or not or if paging is what you want in user mode then by design its much simpler and probably faster to never flick the switch on each context switch. And for the other hand you'll probably end up with a design simular with mine where both kernel and user mode natively runs on segments. Just my unhumble thoughts.

what I have done was support for paging in both kernel and user modes but I think to disable paging in kernel mode only. Running in segmented mode only will need LDT for each task which may harm. but in paging only one segment for code other for data may be needed as common for user applications.
On other hand real mode is imposible as no memory protection and other considerations.

Hi,

ces_mohab wrote: Run kernel with disabling paging, while user applications enable paging. This will reserve benefits of paging and reduce time of mapping in kernel mode. Why not?
;D

One reason is that it's impossible to switch to the kernel (CPL=0) and disable paging at the same time (and impossible to return from the kernel and enable paging at the same time). This means you need to switch to the kernel, then run some kernel code that disables paging (then run more kernel code, enable paging, and return to user-level). Given that you must run some kernel code with paging enabled, you wouldn't gain a lot from running some kernel code with paging disabled (especially considering how often the CPU enters and leaves the kernel - IRQs, exceptions, the kernel API, etc).

Pype.Clicker wrote: the big question is "does setting CR0.PG also flush the TLBs" ? if it does, that will be a performance killer.

According to my Intel manual, writing to CR3 or doing a hardware task switch causes TLB entries to be flushed unless the are marked as "global"; and changing the PG or PE flag in CR0, an MTRR, or the PSE, PGE or PAE in CR4 will flush all TLB entries (regardless of whether they are marked as "global" or not).

Put simply, to minimize TLB flushing mark pages as "global" where possible, and never touch PG, PE, PSE, PGE PAE or MTRRs unless you absolutely must.

ces_mohab wrote:

how will you translate that argument into a physical address ?

This can be done exactly as processor does. But is it more efficient than mapping and flushing TLB may be?? but I think in that way the kernel will take control over all memory directly.

I wouldn't be too sure about that - for fun, write down the steps you'd take to retrieve an 80-bit floating point value from the virtual address 0x12300FFC and load it into a floating point register. Don't forget to add potential data cache misses to your list (including data cache misses your kernel could cause while trying to access the user level code's page tables, and data cache misses your kernel could cause as it stores both parts of the 80-bit number in a temporary buffer).

ces_mohab wrote:Well I am not sure. I read before that processor under real mode is excuting faster than protected mode. And by the way I think that fetching page dirs and tables may be slower than segmented mode. ???

For "always use paging vs. never use paging", if you look at small sequences of instructions paging is slower because of the potential TLB misses. If you look at the system as a whole (e.g. an OS running several independant applications) paging is faster because of easier memory management and swap space control, shared pages, allocation on demand, etc.

For a simple example, imagine an application wants 200 MB of RAM for data. Without paging you'd need to allocate 200 MB of contiguous RAM and that RAM (regardless of whether it's actually used or not) can't be used for things like file system caches to improve performance, and it'll also increase the chance of needing swap space. With paging, the RAM you allocate doesn't need to be contiguous, and it doesn't need to be allocated immediately - you can allocate each page when it's accessed and keep using it to improve performance until then.


Cheers,

Brendan

But why does the kernel load or save a floating point register I think it's task is only saving and loading general purpose registers and if yes what about other registers MMX for example??

3DNow/MMX registers are the FPU registers, just renamed. That way, it was easy - at the time they were introduced - to start using them in new programs without OS support: the system would just save the FPU stack with FPSAVE as it had always done. SSE1/2/3 registers (XMM) are different, and they need to be saved on their own (FXSAVE).

This does not mean, however, that you can't trick the CPU in generating an exception when SSE is used, just like you could for the FPU, MMX and 3DNow: it is possible, but IIRC, it needed a bit of setup. Ask the elders in this forum, for I know nothing more