More processes
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
More processes
Nowadays, when everyone uses virtual memory, LDTs seem like an uneeded concept. However, the number of tasks that can fit in a GDT is limited. I thought about implementing a MMU that uses both virtual memory and LDTs in the following way: all processes are stored in LDTs. When the first LDT gets completely filled, a new one is created in the GDT. I realize that a lot of tasks can reside in the GDT anyway, but using LDTs to increase the space may one day be something useful. Any cooments?
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
Yeah, if you are willing to force your userland apps to run in a very limited-size piece of physical memory, you can do that, I guess. Dynamically allocating memory for tasks would use up even more GDT/LDT entries -- I'd think that you'd need to have a new entry for each allocation. And segments don't work so good in 64bit mode -- so you'd be doing a pretty major rewrite when you convert from 32bit to 64bit.
In my mind, on a small (RAM) machine: physical memory can just run out too fast. Especially with the bloated apps that people write these days. If Firefox eats 500M, and gcc eats 40M, and you only have 512M on your system, then you're dead (or you have to wait for one app to finish, before you can run the next).
In my mind, on a small (RAM) machine: physical memory can just run out too fast. Especially with the bloated apps that people write these days. If Firefox eats 500M, and gcc eats 40M, and you only have 512M on your system, then you're dead (or you have to wait for one app to finish, before you can run the next).
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
I was talking about protected mode. I'm a newbie with 64-bit & compatibility modes. However, it doesn't really matter. I forgot to mention that I was talking about a flat memory model... Just out of curiosity, why do you say segments don't work so good in 64-bit mode?And segments don't work so good in 64bit mode -- so you'd be doing a pretty major rewrite when you convert from 32bit to 64bit.
No, TSS and IDT descriptors would still reside in the GDT. But this way, there will be a lot more space for TSS descriptors as tasks will reside in LDTs.You can't have a TSS descriptor in a LDT.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
Because the CPU doesn't do any boundary checking and task priority is based purely on current code segment descriptor. Also, hardware task switching is unsupported - you need to use stack switching.Love4Boobies wrote:Just out of curiosity, why do you say segments don't work so good in 64-bit mode?
What do you mean, "Tasks will reside in LDT's?". As I said above, TSS descriptors ('tasks') cannot be loaded from LDT's, they must appear in the GDT. This limits you to 8192 entries, minus the NULL segment, minus your code and data segments for user and kernel modes.there will be a lot more space for TSS descriptors as tasks will reside in LDTs.
Cheers,
Adam
You should read up my friend, you seem to have no idea how all this works(somewhat).
Working On:Bootloader, RWFS Image Program
Leviathan: http://leviathanv.googlecode.com
Kernel:Working on Design Doc
Leviathan: http://leviathanv.googlecode.com
Kernel:Working on Design Doc
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
I'm not sure what the hell I was writing before. What I was thinking was actually that TSS, IDT and LDT descriptors will be in the GDT and all other segments processes need will be in LDTs... Of course, there will need to be a list that links each segment in the LDT to each TSS. For flat memory model, however...
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]