Re: Interrupt flow in the NetBSD kernel

[Matt Thomas <matt%3am-software.com@localhost>]

> On Jun 23, 2015, at 12:17 PM, Reinoud Zandijk <reinoud%NetBSD.org@localhost> 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 <reinoud%NetBSD.org@localhost> 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.