Date: Fri, 09 Jun 2006 16:43:17 -0600 From: Scott Long <scottl@samsco.org> To: rookie@gufi.org Cc: "M. Warner Losh" <imp@bsdimp.com>, perforce@freebsd.org, kmacy@freebsd.org, John Baldwin <jhb@freebsd.org>, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: PERFORCE change 98153 for review Message-ID: <4489F985.30502@samsco.org> In-Reply-To: <3bbf2fe10606020733j12bf706em51408b384135e966@mail.gmail.com> References: <200605301926.k4UJQkgt055284@repoman.freebsd.org> <200605311657.44921.jhb@freebsd.org> <b1fa29170606011726r78303d84y3d0116cff2174009@mail.gmail.com> <200606021022.44509.jhb@freebsd.org> <3bbf2fe10606020733j12bf706em51408b384135e966@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Attilio Rao wrote: > 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 > > I demonstrated pretty clearly with if_em that filters beat ithreads by a large margin. Whether or not there is context stealing and all of that magic, there is still the problem of latency caused by multiple interrupt sources sharing the same ithread. If two high speed, high priority devices are sharing the same interrupt vector and thus the same ithread, one will always have to wait for the other to block on locks and do PCI accesses. All other arguments aside, that is the fatal flaw. MSI might help, it will be a long time until legacy interrupt delivery schemes are gone from the PC platform. Heck, we still have to take ISA interrupt delivery into account, and ISA has been dead for more than 10 years! As for context stealing, it's been tried several times in FreeBSD, and has never been found to have a benefit. It's an attractive concept, but implementing it seems to run into hidden costs and problems. If someone can produce a working prototype the demonstrates a benefit, then that's great. But until then, we can't keep on designing our system around features that don't exist. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4489F985.30502>