Date: Wed, 17 May 2000 21:45:55 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Chuck Paterson <cp@bsdi.com> Cc: arch@freebsd.org Subject: Re: Sparc & api for asynchronous task execution (2) Message-ID: <Pine.BSF.4.21.0005172138400.47945-100000@salmon.nlsystems.com> In-Reply-To: <200005171441.IAA24145@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 May 2000, Chuck Paterson wrote: > > First I should point out that his may really be outside > what this api was/is designed for. > > > I am looking at putting the various things currently on the > BSD/OS softint onto several different threads. I looked at using > this code to gang together those items that want to be on the same > thread. This is what really got me interested in this discussion > to begin with. > > Here's the rub. Currently the stuff for queueing > a particular software interrupt is strung together macros, where > it gets handled by function calls with this interface. What really > cause a problem is that the queueing often occurs at the very > deepest point in the stack, say as a worst case ether_input(ip > packet). This means that there will be two more stack overflow > faults and two more stack underflow faults per packet on sparc to > use this interface. With FreeBSD on Sparc there will only be one > additional because of the ip_fastforward() check already took the > stack down one. Actually this probably wants to be fixed also, the > very top of ip_fastforward is short and could be a macro. > > > I'm hoping there is no need to have ip input share a thread > with anything else. If not I'm not sure what the right answer > is. I really like the queue of tasks to run scheme rather than > dedicated bits. I'm thinking of maybe trying to put together a macro > version of the enqueueing to go with this stuff. I didn't realise that every function call involved a fault on the sparc architecture - that sounds pretty nasty. I have been trying to keep the ABI for this system as clear and simple as possible so that binary drivers written to this model are reasonable well insulated from a changing implementation. Enqueuing with a macro would require exposing at least part of the taskqueue structure which is the one most likely to change. One possibility is to specify that the first field in the taskqueue is always an STAILQ_HEAD(, task). A caller using that to enqueue directly would have to be responsible for using a mutex (or whatever) to protect the queue. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005172138400.47945-100000>