Date: Tue, 2 Apr 1996 11:23:05 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Cc: terry@lambert.org, freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Hacked kernel with option to disable "green" mode Message-ID: <199604021823.LAA16657@phaeton.artisoft.com> In-Reply-To: <9603018284.AA828414922@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 08:12:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > OK. I agree. There should be an ioctl to issue a controller command > > for WD controllers -- we have one for SCSI. > > Easy to do, since there's already an "issue a controller command" function > called wdcommand(). What are the conventions for ioctl numbering, > structs passed to ioctls, etc. in FreeBSD? If you're experienced at > hacking this kernel, it shouldn't take more than 15 minutes of coding to > add the new command. Well, then there he goes -- send the 0xFB out that way -- does the 0xFB have to go out at the start, or could we, for instance, send it after initialization? It seems to me the best place for disabling "green" mode would be in a user hack to the /etc/rc.local. > > I would prefer to have a reschedulable one-shot than to directly use > > the timer interrupt. > > > The distinction is that the interrupt can be scheduled as a one shot > > down to the hardware resoloution instead of being limited to the clock > > frequency. > > Either kind of timer would probably suffice. High frequencies and super > resolutions wouldn't be necessary, since disk I/O is a somewhat slow > process. A period of 10-20 milliseconds -- about the same as a typical > disk seek time -- would be sufficient. I was thinking in terms of floppy tapes that: 1) Are not on a FIFO'ed chip 2) Have a 200uS window before they lose resynchronization. The window can be stretched by haveing two buffers in the kernel and alternating them while repositioning the tape, but even the 10ms window that results is unreliable, since you would require either very high priority or no other qunatum use while using the tape. Think "network backup" and you'll realize that it's impossible to have a useful floppy tape driver without the ability to interrupt whatever is going on and hande it within 200uS, without regard to other processes on the machine. Ade's FT driver for BSDI is a good example of how to push out all the possible windows, but 30% of the CPU spent in DELAY() is a bad thing. At the very least, given some IDE or cheap net card overhead (ie: the kind of hardware that is owned by the kind of people who buy floppy tapes), it means the tape can never stream. > > The win here is that I can have a hardware interrupt to cause timed > > service routines in the kernel without giving up RT. > > > This lets you replace recurrening events with rescheduling the > > oneshot, and replace DELAY() with a one-shot scheduling. > > This would certainly work. But the advantage of the timer is that it would > be sharable; the one-shot wouldn't be. Not true. This is why it would have to be a reschedulable one-shot. You would maintain a btree with a link increment delta in a time ordered list. This would allow you to reschedule the one-shot to the smallest remaining delta each time, and subtract the delta from any remaining list elements. This means you couldn't have 5000 of them going at once and still get 200uS, but you wouldn't use it for normal timer things, you'd use it for deadlining (ie: device probes, floppy tape, serial port paritally full FIFO polling, etc.). > In any event, how much would the scheduler and vm modules have to change > -- if at all -- to allow unaffected processes to continue during swapper > I/O? Not at all. That's the beauty of using a real timer interrupt to handle the event. Interrupt processing is handled seperately from the scheduler. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604021823.LAA16657>