OSDev.org

Until recently i was fairly certain that the Physical and Virtual Memory managers in the kernel dealt exclusively in 4kb (page) chunks and then the Clib malloc broke it down into smaller chunks. But now i've heard several people on IRC say that all of the breaking down is done in the Virtual Memory Manager. Surely this requires much more overheads

Thanks in advance for any replies

Pete

I think, this breaking down of memory shall stay in the c lib, for many mallocs would require many traps into the kernel for ... small things. Dealing with small things is not really the kernel's task.

Kernel deals out/takes back memory in size of 4 kb or any other big/fixed size and shall the application do with it what it needs to do.

That's my opinion and my policy in kernel programming. Others may think au contraire.

I know one OS which does even the breaking down of 4 kb chunks into smaller malloc'ed chunks: visopsys. Maybe the author has changed this policy recently.

As soon as you have memory protection set up, calling kernel space for every malloc() will become a serious performance issue. I know of no production-grade solution that does it this way.

Doug Lea's malloc() (often referred to as dlmalloc()) is a very widely-used malloc()-Implementation that was adopted by Linux some time (not sure if it still is). It does rather complex work with linked lists, chunk caches etc. etc. to improve performance, and calls the kernel (sbrk()) only when allocated memory runs out or when large pieces of memory go unused. That enables an application with not-so-volatile memory requirements to handle all the memory management in user space.

I can't see any advantage of doing the handling of 16-byte chunks of memory in kernel space...

Obviously it depends entirely on how you want to do it. The more kernel calls you do, the more overhead there is going to be.

I've currently implemented the major memory allocation routines inside the std c library and my kernel provides 4 KB or 4 MB pages. The libc requests 4 MB pages from the kernel and the libc then breaks that 4MB down into the sizes requested by the application.

This way, I only have the kernel doing memory allocation or freeing now and then as opposed to doing it on every malloc call.



I noticed a noticable (err...) improvement in speed once I implemented the userland allocator.

Also. Does the kernel allocator have to have the ability to allocate multiple consecutive pages (for allocations > 4kb)

Pete

't is of course a fine thing for it takes care of memory fragmentation - but I don't consider this a *very* hard thing. Paging hides this lowlevel stuff from the application, so only the MMU needs to know where which frame is located. everything else - well, the application sees a consecutive area mapped into its adress space. That's what counts. *gg*

And using a stack allocator for handing out physical memory, I have no other choice but to just hand out the *next* free page.

the allocator for "general-use" memory doesn't care about physical contiguousness. Only the ISA DMA worries about this. Afaik, even the UltraDMA is able to cope with buffers scattered in physical memory ...

A safe design (imho) is to dedicate a part of your physical memory for buffers allocation and the rest as the 'pages pool'. The page pool offers no garanty of any contiguity while the buffer allocator does.

Since IO buffers are unlikely to be freed and allocated frequently, even a simple bottom/up watermark allocator does the trick ...

i meant virtual continuity

Thanks all. Time to crack on with coding then

Pete

I think this is good memory manager
Pointer to top of memory used, check if by adding the number of bytes requested we will bust ,
If not give the pointer to the requester and add the the numer of bytes to the old pointer, This is now the pointer to top of memory.

Keep it simple .

ASHLEY4.

ASHLEY4 wrote: Pointer to top of memory used, check if by adding the number of bytes requested we will bust ,
If not give the pointer to the requester and add the the numer of bytes to the old pointer, This is now the pointer to top of memory.

/very/ simple.

Consider what happens when I free a block that I've allocated (can you even do that?).

For mallocs, read up on the buddy algorithm, karels-mccusick, best fit, next fit, first fit, worst fit. They are ways to do it /with/ a free function.

This is it in a nutshell.
Kernel including driver (atapi,vesa,floppy,etc,asm-lib's)
built in is a menu,mp3,dvd,cd player.
All this fits on a bootable floppy
menu =
Load Program
Mp3
Dvd
Cd Player

The floppy image is put on the cd, emulats a floppy.
The rest of the cd is filled with the program to run eg: game,mp3's etc.
The atapi driver is loaded on boot up from the floppy image, so now when you load from cd, it see it like a normal cd, jumping over the boot scetor.

So you put a cd in,and boot it up,you then come to a menu, press to run game ,Then when you end the game, You put another cd in, It jumps over the boot scetor and when you press in the menu to run program ,It jumps to the same spot in the cd, and puts it at the same address in memory ,over writeing the program that was there be for.

For people to make program for the os you get a manual for all the functions.
On booting it checks for ver number if its diffrent from the kernel in memory it ask if you want to reboot.
keep it simple .

ASHLEY4.