On Tue, 14 Oct 2008 09:30:00 -0700 "Alexander Nezhinsky" <nezhinsky@xxxxxxxxx> wrote: > >> Where do you see the benchmark features that may > >> obscure the real-world performance? > > > > My point is that the performance of read-world workload benchmark like > > dbench are relevant for the users than the performances of sequential > > accesses. > > > Right now we are "fighting" the overhead incurred by tgt itself - command > processing time, user-kernel interactions, memcpys etc. > When we perform the measurements involving the null device, there is zero > penalty on random accesses. Thus performance improvements with > sequential access are indicative for any types of load. The performance improvement is really great but only 0.01 percent of iSCSI people would say, "Supporting only scsi devices is ok for performance improvement." It's unacceptable for the majority. Flexible device management is a must. What we really need to do is improving Linux AIO suuport, which benefits not only tgt but everyone. > > Adding this feature is fine but I think there are still some issues if > > this is not just for performance measurements. For example, you need > > to take care of WCE. At least, you need to issue SYNCHRONIZE_CACHE > > when necessary. > > This bs_sg implementation uses DIO at all times. I guess we don't have > to care about WCE because when we send a status to initiator, the data is > not merely written to cache (well, it is not), it has been actually sent to the > i/o device and acked by it. Not correct. Using sg's DIO means nothing for this issue. DIO just represents a way to move data between kernel and user space. For example, we enables WCE by default so initiators send SYNCHRONIZE_CACHE and this sg code ignores it. If a scsi device enables WCE, you are in trouble. I just pointed out using this backing store might cause problems. You can avoid the above problem with a proper configuration so I'll merge this as-is. > >> I think there might be also a place for adding some features that you > >> have termed "passthrough", but this is another issue and i'll write > >> a separate mail on it :) > > > > FYI, 'pass through' is a common SCSI term. > > I know, actually i meant that there is a whole range of possible > implementations, where a varying number of commands are forwarded > to the device. So it is not only about "100% passthrough" or > "zero-passthrough". > > I think this distinction goes beyond the formal definition of the term > pass through, because, in practical terms, we have to carefully choose > the set of commands which are handled internally vs. those forwarded > to the device. That's exactly what all the passthrough implementations do, that is, they choose the set of commands which are handled internally vs. those forwarded to the device. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
