Date: Sat, 01 Nov 1997 19:35:14 -0800 (PST) From: Simon Shapiro <Shimon@i-Connect.Net> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG, dufault@hda.com, "Jamil J.Weatherbee" <jamil@trojanhorse.ml.org> Subject: Re: Strategy Routines Message-ID: <XFMail.971101193514.Shimon@i-Connect.Net> In-Reply-To: <199711020252.NAA00521@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mike Smith; On 02-Nov-97 you wrote: > > > > period. Now I know that if the drivers routine can be interrupt driven > > the this is all solved, but if (as in digital_out_strategy() in > > labpc.c) > > someone passes a 1/2 megabyte buffer, youv'e got a problem as your > > going > > to be out of business for at least .5 seconds. So how can the > > equivalent > > of reschedule() under the linux kernel be done in here. You could then > > limit yourself (in the drivers) to say 1024 bytes written then a > > reschedule() to maintain the interactivity. > > This is a fault in the driver design. Drivers should not hog the > cpu, obviously. Try calling tsleep() out of the driver with a very > short timeout. Another thing to try is soft interrupts; Setup the copy, shcedule software insterrupt. The software interrupt routine gets control, copies a chunk, does the bookkeeping. If not done, schedules another interrupt and returns. I think it has lower overhead than tslepp and the added advantage that it will not panic if called outside a user context. --- If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.971101193514.Shimon>