1 GB for a Higher Half Kernel?

[mrjbom]

I'm making a higher half kernel and I'm thinking about which piece of virtual memory to give to the kernel.
The standard solution with 3 GB for the user space and 1 GB for the core is good, but since usually with a physical memory size of 4 GB or more, the size of available physical memory is 3.5 GB (I don't use PAE),
I am afraid that I will have some free physical memory left. I believe that the kernel is unlikely to need more than 100 megabytes of physical memory, so the remaining 400 megabytes will be lost.
Is it worth sticking with this 3/1 GB option?

[rdos]

1GB virtual memory reserved for kernel doesn't mean you reserve 1GB of physical memory.

[thewrongchristian]

I'm making a higher half kernel and I'm thinking about which piece of virtual memory to give to the kernel.
The standard solution with 3 GB for the user space and 1 GB for the core is good, but since usually with a physical memory size of 4 GB or more, the size of available physical memory is 3.5 GB (I don't use PAE),
I am afraid that I will have some free physical memory left. I believe that the kernel is unlikely to need more than 100 megabytes of physical memory, so the remaining 400 megabytes will be lost.
Is it worth sticking with this 3/1 GB option?

Yes, but this split is for the virtual address space, not the physical address space. You kernel will have the full 1GB of address space to work with.

A higher half kernel cares not where physical memory is located, If you load with grub and multi-boot, for example, and follow the Higher_Half_x86_Bare_Bones as an example, you'll be loaded into physical memory at 0x00100000 (1MB), and the kernel will be mapped at 0xc0100000 (3GB + 1MB).

If you manage your kernel address space like a user address space, using segments which indicate mapping type and backing memory, then you only really need as much address space for the kernel's data and windows of mapping into files.

For example, old 32-bit Solaris on x86 used to use a (from memory) 256MB kernel address space at the top of virtual memory (0xf0000000-0xffffffff), leaving 3.75GB address space for user space.

My own kernel uses uses the same split of kernel address space as Solaris, yet supports gigabytes of RAM (though not yet PAE). All kernel address space is managed with the same mapping structures as user space, so things like page fault handling use the same routines for kernel mappings as for user mappings, and very little has a fixed mapping (basically, the initial kernel image, memory mapped I/O).

Physical memory just becomes a pool of pages with which to satisfy predominantly demand loaded mappings.

[mrjbom]

Oops, I forgot something that each user process has its own 3 GB of virtual memory, which means that all free physical memory can be used.