PERFORCE change 98153 for review

Attilio Rao asmrookie at gmail.com
Fri Jun 2 14:33:28 UTC 2006


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


More information about the p4-projects mailing list