|Daniel Eischen||Jul 30, 2001 1:18 pm|
|Julian Elischer||Jul 30, 2001 2:18 pm|
|Warner Losh||Jul 30, 2001 2:20 pm|
|Daniel Eischen||Jul 30, 2001 3:38 pm|
|Julian Elischer||Jul 30, 2001 3:45 pm|
|John Baldwin||Jul 30, 2001 3:47 pm|
|Julian Elischer||Jul 30, 2001 5:33 pm|
|Julian Elischer||Jul 30, 2001 6:47 pm|
|Daniel Eischen||Jul 30, 2001 9:15 pm|
|Peter Wemm||Aug 1, 2001 1:39 pm|
|From:||Julian Elischer (jul...@elischer.org)|
|Date:||Jul 30, 2001 2:18:51 pm|
Well, I'm quite a way into doing the KSE kernel.
I have changed most of the interfaces to pass threads around instead of procs and have the compile going almost all teh way through everything upto teh end of 'kern' working with anly a few minor errors.
however there sre some things that need to be discussed... these include:
behaviour of a multithreaded program when stopped by the debugger, and what happens when the user type ^Z on a multithreaded program.
What iti comes down to is if a particular process is running on several processors, and the user hits ^Z, how do I stop the threads that are running on the other processors?
My guess is that I send some sort of Inter-processor Interrupt, after having marked the process as stopped, and that on teh return from the interrupt, the kernel on teh other processor should notice this fact and deschedule its thread and run something else.
I have also some really difficult times in trying to work out how to tranlate such things as teh calls to put a process on teh run queue..
here's what I have at the moment for a first cut: (For this example assume a 2 processor system)
initial state: nothing on run queues, several threads on sleep queues. Two KSEs have been created in one KSE group.
Thread 1 becomes runnable.. we find the last KSE it ran on, and as it is not runnable, we make THAT runnable, and put it on the run queue. We hang the runnable thread off the KSE. (note at this stage there is only one run queue).
A processor picks the highest priority KSE and takes it off the run queue and starts processing the first thread hung off it.
Thread 2 comes ready. It also was last run on KSE-1 so it is hung off the already running KSE-1. However since the number of runnable threads is greater than the number of runnable KSEs, but less than the number of KSEs created (2) we get another KSE at random (KSE-2) and place it on the run queue.
KSE-2 starts and finding no work, steals a thread from KSE-1.
[note: is it better to preserve the processor affinity or to run earlier?]
Thread 1 blocks, and is saved back in the sleep queue.. A new thread is created and returns to the UTS. (thread3)
Threads 4, 5 & 6 become runnable. They are placed on the queue for KSE-1 as that is where they last ran.
Thread 2 blocks. KSE-2 has no more work, but, as it still has quanta, it steals thread 4 from KSE-1's queue.
Thread 3 blocks. As there are runnable threads, no new thread is created (yet), but thread 5 is run instead up to the user boundary. It doesn't return top user space, but it's return state is passed to teh USer-space structure reserved for it, and it is freed, and thread 6 is loaded onto the KSE. It also runs to the userland boundary, and saved to userspace. SInce there are no further runnable threads in the kernel, control is passed up to the UTS.
Quantum becomes exhauseted..
KSE-1 and KSE-2 place the presently running threads back on their queues (possibly at the tail if not in a critical section) and then are themselves placed back on the run queue. (at the tail)
I have not coded the userland boundary crossing stuff yet, so at this stage there can only be as many threads as there are KSEs and the mapping is permanent. syscalls return directly instead of producing an upcall to the UTS.
Basically the mechanism should be the same but it will never have the oportunity to do some of the cases.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message