The Place to Start for Operating System Developers
http://forum.osdev.org/
No, because the kernel heap allocator should not allocate physical memory -- that's the job of the physical memory manager.elaverick wrote:Ok, but I understood that paging is generally set up to take the entire 4GB of potential space. If the heap allocator doesn't touch the paging tables isn't there a risk that the paging algorithm will attempt to allocate physical memory that is in use by the heap?
It sounds to me like what most kernels do, except that I think they use more than two or three pages.I was thinking that you might allocate two or three pages and then sub-divide them with the kernel heap, but that doesn't doesn't seem to be the approach anyone else takes to this.
In general there's 3 completely different "levels".elaverick wrote:Could anyone point me in the right direction for those (assuming I've not got this completely round my neck just yet :) )
Code: Select all
void *allocTDS(void) {
void *stack;
TDSstruct *TDS;
stack = kalloc( 4096 );
if( stack == NULL ) return NULL;
TDS = kalloc( sizeof( TDSstruct ) );
if( TDS == NULL ) {
kfree( stack );
return NULL;
}
TDS->kernelStack = stack;
return tds;
}
void freeTDS(TDSstruct *TDS) {
kfree( TDS->kernelStack );
kfree( TDS );
}Code: Select all
TDStruct TDStable[MAX_THREADS];
unsigned char *KernelStackTable[4096][MAX_THREADS];Code: Select all
freePage(&TDStable[threadID]);
freePage(&KernelStackTable[0][threadID]);For me and my OS design, the permanance of the data structures, the additional control the kernel gets over when allocation and de-allocation of pages occurs, and the performance improvements it can give for allocations, make static allocation the best method for me. Of course this doesn't necessarily apply to other people and/or other OS designs.... ;)elaverick wrote:Just so I'm sure I've got this right... what you're suggesting is that due to the permenance of the data structures you find in a micro-kernel (and because a micro-kernel is so centred on the generic jobs and doesn't stray into the realms of device drivers) you are often better using static allocation as it will be faster because you don't have to go searching for the areas of memory you need in run time.
The compiler itself doesn't know anything about paging or memory management. All it does is put things where the programmer tells it to put things. Sometimes the compiler puts things on the stack (function arguments and most local variables), sometimes it puts things in the ".data" section ("char foo = 'A';"), sometimes it puts things in the ".bss" section ("char foo;") and sometimes it puts things at an address it knows nothing about ("*((char *)0xB8000) = 'A'" or "*pointer = 'A'").elaverick wrote:Does this mean then that if you have statically allocated data structures that are smaller the 4kb alignment (say a single char for example) that this will be expanded to take the full 4kb of a page essentially wasting 4095 bytes of memory? Or is the compiler clever enough to realise and only 4kb align variables above a certain threshold?
Code: Select all
void *SMEMkernelAPITable[1024] __attribute__ ((aligned (4096)));
struct SIB SMEMsystemInfoBlock __attribute__ ((aligned (4096)));