OSDev.org

I've been working on my Mem Mgr, and I have two implemented in my kernel. A rudimentary, crude one that, at startup, makes the assumption that there is 1MB memory in all, and uses a bitmap to handle pages. This crude mem mgr only keeps track of pages in lower mem.

It automatically maps the first page in lower mem as being used, and then goes on to map all mem pages above 512KB up to 1MB as being used as well.

Its purpose is to ensure there is a competent (enough) allocator for resources during the initial stage of setting up the kernel process. The very first thing my kernel does is set up its own process. I have use an array[8096] of type proc_data_t (which is 48B per entry) to keep tabs on processes.

This implies that my kernel will have a maximum number of 8092 processes. And the array is given pages in Low Mem, as I indicated above.

As soon as the kernel process's data is filled out in the second index of the array (index 0 is a null process, and index 1 is the kernel), the REAL McCoy Mem Mgr is brought out, and implements paging, and whatnot.

The math for the Low Mem indicates that below 512KB there are approx 128 pages. And allocating 8092*48B = 95 pages. Please note that I KNOW I'm overwriting the Bootloader @ 0x7C00.

This max number of processes has been bothering me, so I wonder: does it make sense? Have you ever seen any 'puter with more than even 4000 processes? Would a server PC be running more than 8092, by chance?

That should be plenty of processes - afaik, Linux has a max of 32768 processes, and most of the time on my box there are only ~70 processes (1-2 running). You can also assume at least 4 MB of memory on a machine that can use protected mode. You should also try to dynamically allocate those process structures somehow. I suggest having a 2D array where the sub-arrays are allocated on demand.

NickJohnson wrote:That should be plenty of processes - afaik, Linux has a max of 32768 processes, and most of the time on my box there are only ~70 processes (1-2 running). You can also assume at least 4 MB of memory on a machine that can use protected mode. You should also try to dynamically allocate those process structures somehow. I suggest having a 2D array where the sub-arrays are allocated on demand.

Yes, a (possibly, but not necessarily, doubly) linked list would be best I think and the least memory-absorbing.

That gives me an idea, actually: I could leave the 8092 processes as they are, in low mem, and then, probably, the kernel would keep track of processes, and if more than 8092 processes are needed, I could, from there, have a "higher processes" linked list, which handles all processes above 8092. Maybe...

holypanl wrote:That gives me an idea, actually: I could leave the 8092 processes as they are, in low mem, and then, probably, the kernel would keep track of processes, and if more than 8092 processes are needed, I could, from there, have a "higher processes" linked list, which handles all processes above 8092. Maybe...

I would say its a waste of memory. a linked list or something of that sort would be much better

earlz wrote:

holypanl wrote:That gives me an idea, actually: I could leave the 8092 processes as they are, in low mem, and then, probably, the kernel would keep track of processes, and if more than 8092 processes are needed, I could, from there, have a "higher processes" linked list, which handles all processes above 8092. Maybe...

I would say its a waste of memory. a linked list or something of that sort would be much better

True. But the array is also allocated within lower memory. I'm not entirely sure, but lower memory isn't normally needed when an OS goes into full swing. Does Windows or *Nix use lower memory for anything?

holypanl wrote:I'm not entirely sure, but lower memory isn't normally needed when an OS goes into full swing. Does Windows or *Nix use lower memory for anything?

Lower memory is just more memory, which is meant to be used. Do you really think common OSes would forego memory that works the same way as higher memory? It also has another advantage: it can be used for ISA DMA transactions.

Creature wrote: Yes, a (possibly, but not necessarily, doubly) linked list would be best I think and the least memory-absorbing.

But if you want to find a process quickly, a two-level array would be much better. I have an area of virtual memory that works as a linear table of processes, but the pages behind it are allocated on demand, so at most a page of memory is wasted at a time. Using the heap to allocate each process entry individually (to put in the linked list) would probably take more memory and time in the end.

holypanl wrote:Does Windows or *Nix use lower memory for anything?

The chunk of lower memory from 0x500 to 0x80000 (or up to 0xF8000) can be used just like any other memory, so it's usually added to the pile of frames like extended memory. Half a megabyte can always be useful.

Combuster wrote:

holypanl wrote:I'm not entirely sure, but lower memory isn't normally needed when an OS goes into full swing. Does Windows or *Nix use lower memory for anything?

Lower memory is just more memory, which is meant to be used. Do you really think common OSes would forego memory that works the same way as higher memory? It also has another advantage: it can be used for ISA DMA transactions.

Great point about the DMA space thing. I suppose I should really do something about that. Although, I wonder how many KB it normally takes to handle a DMA transaction, really? IIRC the DMA has a max num of bytes you can handle at once or something. I haven't read into it extensively yet, though.

Anyway: thanks for the tips peeps.

Combuster wrote:

holypanl wrote:I'm not entirely sure, but lower memory isn't normally needed when an OS goes into full swing. Does Windows or *Nix use lower memory for anything?

Lower memory is just more memory, which is meant to be used. Do you really think common OSes would forego memory that works the same way as higher memory? It also has another advantage: it can be used for ISA DMA transactions.

But ISA DMA can use the first 16MB of physical memory, not just lower memory. Not to mention that only a couple of devices (i.e. floppy drives) still use ISA DMA, mostly because it sucks.

IMHO using linked lists for process control blocks is the best thing to do. There is no pressing need to go for arrays, as the way a scheduler would schedule processes doesn't need you to optimize by doing arrays, unless you are concerned of the sole advantage of fast pid lookups.

Having arrays also means that you would have to keep track of empty locations in the array when processes are removed. This entire process i think, would be much simpler in a linked list.

When you have linked lists, the limit of number of processes would naturally be limited by the resource: memory. You don't have to worry about number of processes. IIRC, unix uses the 16 bit pid for unix compatibility and hence in your OS, you can have as many processes possible as you want.