OSDev.org

The Place to Start for Operating System Developers
It is currently Sat Apr 27, 2024 2:02 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: 1 GB for a Higher Half Kernel?
PostPosted: Thu Mar 28, 2024 2:06 pm 
Offline
Member
Member
User avatar

Joined: Sun Jul 21, 2019 7:34 am
Posts: 300
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?


Top
 Profile  
 
 Post subject: Re: 1 GB for a Higher Half Kernel?
PostPosted: Thu Mar 28, 2024 2:20 pm 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3195
1GB virtual memory reserved for kernel doesn't mean you reserve 1GB of physical memory.


Top
 Profile  
 
 Post subject: Re: 1 GB for a Higher Half Kernel?
PostPosted: Thu Mar 28, 2024 2:27 pm 
Online
Member
Member

Joined: Tue Apr 03, 2018 2:44 am
Posts: 403
mrjbom wrote:
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.


Top
 Profile  
 
 Post subject: Re: 1 GB for a Higher Half Kernel?
PostPosted: Thu Mar 28, 2024 3:02 pm 
Offline
Member
Member
User avatar

Joined: Sun Jul 21, 2019 7:34 am
Posts: 300
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Majestic-12 [Bot] and 21 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group