Garrett D'Amore writes: > Streams itself uses locks (syncq's) when crossing module boundaries. So > although removing perimeters *should* help performance, it won't (by > itself) achieve full performance. (Locks have to be used with streams > to protect against plumbing changes -- one of the most powerful features > of streams is, in this case, its worst problem.)
putnext(9F) is a bit more optimized than that. By default, we briefly take the sd_lock mutex on the stream itself, fetch the syncq, and then take a *per-CPU* sq_ciputctrl lock. While holding that lock, all we do is check the flags and increment a reference counter. The actual put(9E) call is made (of course) without the locks held. So, yes, there are locks that get held, but they're pretty cheap, quick, and _local_ locks, which means that unless you're doing something special (such as messing about with perimeters or enabling flow tracing), performance ought to be awfully close to just an extra function call's worth of overhead. If it's not, then there's probably more work that should be done in optimizing this code. (Perhaps we're just quibbling over what "full performance" actually means in this context. I can't say that I've seen the default operation of MT STREAMS to be 'slow' in any real respect, but it's pretty easy to fall into performance-sapping traps by queuing messages, invoking flow control, or contending on locks by accident.) -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
