PERFORCE change 98153 for review

[Kip Macy]

I can't say how the two compare. But the lack of context stealing
undermines the value of our ithreads as far as I can tell.

     -Kip


On 6/2/06, Attilio Rao <asmrookie at gmail.com> wrote:
> 2006/6/2, John Baldwin <jhb at freebsd.org>:
> > On Thursday 01 June 2006 20:26, Kip Macy wrote:
> > > > I'd rather avoid this for now as it will have to be backed out for
> > interrupt
> > > > filters.
> > >
> > > I don't know anything about interrupt filters, so please let me know
> > > what you have in mind. The whole of interrupt handling is far too
> > > heavyweight at the moment.
> >
> > With interrupt filters you can have both an INTR_FAST style handler and a
> > threaded handler, and the INTR_FAST style handler will have a return value to
> > determine if it's associated ithread should be scheduled and to let the
> > calling code know if it has handled the interrupt so that it doesn't need to
> > be masked, or if the interrupt wasn't for this device at all.
>
> I was wondering, it would not be better writing a complete ithread
> mechanism (including lazy scheduling/context stealing) instead using
> ifilters? I don't know if this is fair, but, commonly, ithread seems
> having better performance than ifilters (when correclty managed).
>
> Attilio
>
>
> --
> Peace can only be achieved by understanding - A. Einstein
>