Date: Thu, 9 Mar 95 10:16:06 MST From: terry@cs.weber.edu (Terry Lambert) To: bakul@netcom.com (Bakul Shah) Cc: joerg_wunsch@uriah.heep.sax.de, henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org Subject: Re: QIC-80 problem Message-ID: <9503091716.AA06567@cs.weber.edu> In-Reply-To: <199503090229.SAA18798@netcom21.netcom.com> from "Bakul Shah" at Mar 8, 95 06:29:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Not on the same descriptor, that's true. You'd need to dup it. > > Okay, you can do this but how do you assure serializability? > Say you are doing > > tar zcf - ... | steam > /dev/tape > > and steam dups fd 0 multiple times and starts async io on > all of them. How can you figure out which fd has data from > what offset? The offset where a read or write starts can > really mess you up because you can not explicitly specify > it with read/write. Simple; serialization doesn't require that the reads be in any particular order, only that the writes be in order. All you really have to do is keep track of where the reads come from to make sure they are written in the right order; remember that it is the disk I/O on the read that you are trying to avoid, not the system call overhead. In reality, you probably don't need async I/O for the writes as long as O_SYNC isn't set, which it shouldn't be for this application (power failure during tape I/O is rarely recoverable in any case). > If you use LWP (nee threads) you have not gained much if any > over team. > > Also, the overhead of context switch is pretty low these days: > < 1ms, right? Even on a 250KB/s streamer tape, with 64KB block > size you need no more than four switches for write (and four > or more for reads). These two statements are synonymous. LWP, however, isn't threads; competitition for quanta occurs in a single process context. Using aio is much lighter weight than using LWP because you don't drag in the LWP scheduling abstraction with it, nor the register window flushing, stack swapping, FP state saving, nor signal and errno handling. > Go ahead and write (or urge others to write) a team replacement > but I just wanted to point out that context switch is not a > problem. If your system is so busy that it becomes a problem, > a uni-process impl. will not really save you. Second, just > because team breaks on Sun MP is no reason to throw it out on > FreeBSD (well at least until it runs on a MP system). Admittedly, the context switch issue is _relatively_ less of a problem (I won't say that it isn't a problem entirely). But there is also the issue of the token passing using pipes between the process, etc.. An implementation using aio in a single process context would avoid a lot of system call overhead as well as context switch overhead in the token passing, and also avoid things like pipe read/write latency, since team does NOT interleave that. Not that I would throw the baby out with the bath water, since the baby is actually the idea of interleaved I/O in the first place, not the code embodying the idea, but the overhead of pipe I/O and of context switching *is* non-zero, so it *could* be even faster. And since the problem in the ft case is competition for process quantum, not creating more than one competing process will aid in resolving the problem. Anyway, just an idea -- I'd prefer that the ft driver become immune to system load, actually -- it would put it a hell of a lot in advance of many commercial ft driver (some commercial UNIX implementations still don't even have an ft driver at all, let alone one that is robust under heavy system load. 8-). Terry Lambert terry@cs.weber.edu --- 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?9503091716.AA06567>