Paging in ring3, Segmentation in ring0 ?

[Assembler]

Hi guys,
I've got a strange idea.
What if the kernel use paging in ring3 user processes while use a segmentation without paging in ring0 or kernel space ?

This method has some benifits:
1- Pure segmentation has higher perfomance than paging which will increase the performance in kernel space and memory access will be faster.
2- Since the memory manager knows which pages is mapped for which process, then there is no problem for the kernel to access any process area.

This may be silly but anyway any ideas ??

Assembler,

[Brendan]

Hi,

What if the kernel use paging in ring3 user processes while use a segmentation without paging in ring0 or kernel space ?

This method has some benifits:
1- Pure segmentation has higher perfomance than paging which will increase the performance in kernel space and memory access will be faster.
2- Since the memory manager knows which pages is mapped for which process, then there is no problem for the kernel to access any process area.

The first problem is that every time user level code calls any kernel function you'd need to disable paging and re-enable it, which will cause all TLB entries to be flushed. Every system call will become almost as slow as a task switch. The same problem occurs for IRQs and exception handlers.

It'd make passing data to/from the kernel hard. For example, imagine you've got a kernel function that converts a UTF8 string into UTF32LE, where the user code gives the kernel a pointer to the UTF8 string and a second pointer to a buffer (where the UTF32LE string will be put). For the kernel, these pointers are meaningless - it'd have to convert the linear addresses into physical addresses, and then while it's converting the string it'd need to be very careful when it crosses any page boundary. Consider what happens when the second pointer is 0x123FFE - the kernel needs to convert this into a physical address, store the lowest 2 bytes of the first character, then convert 0x124000 into a physical address and store the next 2 bytes of the first character. Normally I'd just use "stosd". Linear to physical address conversion and constantly checking for page boundaries will slow down any kernel function that accesses user level data.

Next, when paging is enabled or disabled the code must be identity mapped. This means your kernel must use statically allocated pages at the beginning of the linear address space - i.e. you can't have the kernel at 0xC0000000, you can't send kernel pages to swap and you can't dynamically allocate kernel pages (e.g. use pages that are suited to specific NUMA domains, etc). It also becomes impossible to port to long mode.


Cheers,

Brendan

[Pype.Clicker]

I've got a strange idea.
(...)
This may be silly but anyway any ideas ??

I'd say forget it. if you wonder why, read brendan's arguments ... Keep in mind that those documents saying "paging is slow" mainly dates from 386 times where you had no fine control over the TLB cache.

If you're concerned about performance issues due to paging in kernel mode, just preallocate memory for the kernel (4MB or something), map it all consecutively, with "global" mappings (e.g. remaining persistent even on address space switches) and live with that

[Assembler]

If you're concerned about performance issues due to paging in kernel mode, just preallocate memory for the kernel (4MB or something), map it all consecutively, with "global" mappings (e.g. remaining persistent even on address space switches) and live with that

That's a good idea that i already thougth of, but i think 4 MB will be alot of memory to allocate in old machines since i want my library to be small, portable and supports systems with low memory.
Anyway, i will try both all idea and make some kind of benchmarks.

Thanks,
Assembler,

[Pype.Clicker]

then you might want to have something like

Code: Select all

system memory = 4MB
if total memory < 16 MB then system memory = total memory / 8
if system memory < bare_minimum_you_can_afford
  then panic.

[Assembler]

then you might want to have something like

Code: Select all

system memory = 4MB
if total memory < 16 MB then system memory = total memory / 8
if system memory < bare_minimum_you_can_afford
  then panic.

That's a good idea, but this should be done by the OS not the lib.
The OS should choose its on strategy for the memory managment while the lib should just provide funcitons for paging, as set_pagedir() and set_pagetable() or map(virt, linear) and so on.
But since the lib acts as the cr0.o of kernel it should know from the beginning what is the strategy of the OS is, or i will try to use PIC.

[Pype.Clicker]

i will try to use PIC

i assume you're talking about Position Independent code here, right ?
i'd say forget it too. You may want to read the ELF specifications and see how PIC is actually implemented through GLT, GOT, LPT and the like, but i doubt you'll be willing to support that in your kernel (at least). It can be perfectly suitable for user-level dynamic libraries, though.

[Assembler]

i assume you're talking about Position Independent code here, right ?
i'd say forget it too. You may want to read the ELF specifications and see how PIC is actually implemented through GLT, GOT, LPT and the like, but i doubt you'll be willing to support that in your kernel (at least). It can be perfectly suitable for user-level dynamic libraries, though.

I will never use gcc to output pic kernel, i just meant to write a assembly pic, but i realized that would be a sily idea
But I've already forgot about it.

btw I'm not writing my own kernel just my library