Date: Fri, 2 Jun 2006 16:33:23 +0200 From: "Attilio Rao" <asmrookie@gmail.com> To: "John Baldwin" <jhb@freebsd.org>, kmacy@freebsd.org, perforce@freebsd.org, "Hans Petter Selasky" <hselasky@c2i.net>, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: PERFORCE change 98153 for review Message-ID: <3bbf2fe10606020733j12bf706em51408b384135e966@mail.gmail.com> In-Reply-To: <200606021022.44509.jhb@freebsd.org> References: <200605301926.k4UJQkgt055284@repoman.freebsd.org> <200605311657.44921.jhb@freebsd.org> <b1fa29170606011726r78303d84y3d0116cff2174009@mail.gmail.com> <200606021022.44509.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2006/6/2, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10606020733j12bf706em51408b384135e966>