Code: Select all
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M/MU d- s:- a--- C++++ UL P L++ E--- W+++ N+ w++ M- V+ PS+ Y+ PE- PGP t-- 5- X R- tv b DI-- D+ G e h! r++ y+
------END GEEK CODE BLOCK------Well, the reason people don't have competitions is because the goals tend to be different. For example, if i'm writing a kernel that is meant for desktop use, i have ring 3/ring 0, my tasks have info stored about them (like a bitmap for i/o ports associated with them), etc, and someone else has a bootloader with a kernel that uses the bare minimum to multitask with, he can probably fit more processes in memory than myself, but then again, that doesn't make them useful. Also, I was going to do some testing with my multi-tasking code, what priority are these tasks supposed to run at, because I know in bochs it takes a long time to spawn a lot of threads once they start adding up, unless I put all the threads on pause besides the one creating the new threads. (my threads start as soon as spawned, so it gets slower and slower each task beacuse it has to cycle through all tasks, because getting back to the task that is spawning the tasks).senaus wrote:Hey everyone,
I've been stress testing my kernel lately, and came up with an idea. We don't seem to have any competition/comparison between our projects, so lets start!
I want to see whose kernel can handle the most running threads. Post screenshots, code, videos, or whatever. No cheating.
I got up to 6,000 this morning before I ran out of memory (32MB). I'm going to crank that up to 512MB later, and then I'll post some screenshots
Have fun,
Sean
Yeah, each one of my tasks spawns a 4k stack, 4k for the page directory, 4k for a page table, an entry in my process list, and some other misc. stuff. I do plan on re-working a LOT of my memory management, thread/process management code in the near future, so hopefully I can bring up the # of tasks a bit, work my code for running tasks so a higher priority thread is called more often, not just alloted a bigger time slice, that should help fix my problem of generating tasks slowly (or i guess I could run it on a real machine or in another faster emulator instead of bochs).pcmattman wrote:My current kernel chokes at around 150 threads.
Lately I've been having a lot of trouble with memory in my OS and have been debugging it extensively. If you reduced the thread stack size you could probably get away with many more threads.
In my test all the threads were running under the same process which had one address space, so I didn't need a new page directory, etc. for each thread, just a 4k kernel stack.Ready4Dis wrote:Yeah, each one of my tasks spawns a 4k stack, 4k for the page directory, 4k for a page table, an entry in my process list, and some other misc. stuff. I do plan on re-working a LOT of my memory management, thread/process management code in the near future, so hopefully I can bring up the # of tasks a bit, work my code for running tasks so a higher priority thread is called more often, not just alloted a bigger time slice, that should help fix my problem of generating tasks slowly (or i guess I could run it on a real machine or in another faster emulator instead of bochs).
Yeah, like I said, it makes comparisons easier when everyone is doing the same thing, which in OS dev isn't that common (unless you find a bunch of people making a Unix clone). I did 2 things to help speed up my task creation, first I put, in the infinite loop, a call to relinquish the rest of that tasks time, so the task switch would not even wait the time that each task was allocated, second, I then started each task as sleeping so they are skipped when it's time for their time slice, and then I wake them all up at the end. Yes, removing 8k from each process would probably make it run out ot memory less quickly. I realize that I am creating a PDE and stack, but I was not creating a new PTE because it was just a function from within the kernel (which is copied from the original PDE). So each of my tasks takes 8k, if I didn't generate the PDE, I Would save myself 1/2 the memory used for the tasks, so it should just about double. 8k per task in a perfect world is 4k tasks. Bochs doesn't actually give me the entire 32mb (well, I only use memory above 1mb, below is reserved for DMA right now, this may change later to use it if we run out of regular, but for now I don't). Also, I am loading my kernel + ATA, FDC, Keyboard, Mouse, etc drivers, so they do also take some space, as well as my memory manager, task manager, etc. I was able to hit just under (like 3 less than) 4,000 tasks, so not to horrible, if I change them over to threads and only use a new stack, I can even use a smaller stack if I want if it's a thread, since most threads won't need more than 1k (although it's much less safe this way). The maximum number of threads should pretty much be guessable (within a few hundred) based on what each task is using, so it isn't really much of a challenge per say, I could give each task a 16-byte stack and generate a hole bunch, but that isn't really a true test since most tasks will use more than 64-bytes (while my loop forever and do nothing task doesn't, only needs to store the registers + a few for the function calls).AlexExtreme wrote:In my test all the threads were running under the same process which had one address space, so I didn't need a new page directory, etc. for each thread, just a 4k kernel stack.Ready4Dis wrote:Yeah, each one of my tasks spawns a 4k stack, 4k for the page directory, 4k for a page table, an entry in my process list, and some other misc. stuff. I do plan on re-working a LOT of my memory management, thread/process management code in the near future, so hopefully I can bring up the # of tasks a bit, work my code for running tasks so a higher priority thread is called more often, not just alloted a bigger time slice, that should help fix my problem of generating tasks slowly (or i guess I could run it on a real machine or in another faster emulator instead of bochs).
I also need to change my code so that a higher priority thread gets executed first - I do the same as you and just give a bigger timeslice.
I managed to get it to spawn tasks fairly quickly despite this. What I did was in the thread that was spawning the thread, disable preemption for that thread, create 500 new threads, call schedule() to let them run, do 500 more next time the thread is run, etc.
Code: Select all
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M/MU d- s:- a--- C++++ UL P L++ E--- W+++ N+ w++ M- V+ PS+ Y+ PE- PGP t-- 5- X R- tv b DI-- D+ G e h! r++ y+
------END GEEK CODE BLOCK------Then you later said this:I just ran a stress test on my new scheduler/thread code. With 32MB RAM, it gave up at around 15,500 threads with out of memory. I upped the RAM to 512MB and it appears to have frozen at 30,401 threads:
I am a little confused because the math doesn't work out:In my test all the threads were running under the same process which had one address space, so I didn't need a new page directory, etc. for each thread, just a 4k kernel stack.
