> On Jun 23, 2015, at 12:17 PM, Reinoud Zandijk <rein...@netbsd.org> wrote: > > Hi Matt, > > On Sun, Jun 21, 2015 at 01:42:38PM -0700, Matt Thomas wrote: >>> On Jun 21, 2015, at 12:02 PM, Reinoud Zandijk <rein...@netbsd.org> wrote: >>> On Sun, Jun 21, 2015 at 08:01:47AM -0700, Matt Thomas wrote: >>>> IMO, softints are an abberation and should really be thread priorities >>>> and dealt by the thread scheduler. >>> >>> Each level of softint as a kernel thread that gets woken up by condition >>> variables? >> >> I envision them being hard realtime kernel threads that would preempt lower >> priority threads. > > as in kernel priority threads that get sheduled immediately when they can? > without preemption?
Yes. In theory it could be any thread but it they would most likely be kernel threads. >>> Could in a virtualisation context those threads also be used and be woken >>> by signalling the relevant condition variable on reception of say an >>> virtio push? >> >> Could be. >> >> But my goal is something intrinsically different. In the interrupt, you >> signal a condition variable or some other method of making a thread >> runnable. A run though the scheduler happens and new thread is selected to >> run. >> >> In addition to exceptions and interrupts using a common trapframe, >> cpu_switchto should also need to use a trapframe to store the lwp?s context. >> When restoring a trapframe, switchto will need to know which type of >> trapframe it was. >> >> When the interrupt is about to restore the trapframe, if the scheduler >> decided to switch to another lwp, it will do so using that lwp?s trapframe. >> >> The goal is to have near instant context switching without the hackery of >> the current preeemption code. > > This sounds good, esp. if that means we are leaving the concept of `interrupt > context' other than the short time before it makes its handling thread > runnable. That’s my goal. Fast context switch would go away since it would no longer be a special mechanism. > Leaves us with inventarising and porting the drivers to use the new mechanism. > Would maybe also be a good idea to clean up our forrest of primitives as so > far they are still used. We keep around too many kernel threads which are kept idle for most of the time. Instead we should use a work-crew approach and select an idle worker to do a task. When it’s done, it goes looking for some more work. > How much time do you recon its going to take to do it properly? Could TNF be > tempted to sponser someone, maybe you even ? :) Depends on the port. I’ll probably use MIPS to test the initial work since gxemul makes it easy to test on. I’d take money to work on this.
