>> It seems that bs work takes a lot of time. For example: if I run >> disktest on the same device directly from the target machine (i.e. tgt >> is not involved) in the following way: >> >> disktest -PT -T100 -h1 -K64 -B256k -ID /dev/sdc -r >> >> I get ~13000 iops -> each IO takes ~77 us (compared to 130 us only for >> bs work with tgt). I'm not familiar with the bs code in tgt, so I'm not >> sure what should be done here. >> > > The problem is that Linux lacks a nice event notification > mechanism. The main thread uses epoll to wait on events. I/O threads > (pthread) use pipe to notify the main thread of I/O completion. It's > not effective at all. > >
If I understand correctly, it sounds like a major problem in stgt (that also affects other protocols - not only iSCSI). When a SCSI cmd is done, it takes time until the iSCSI (or any other protocol) layer is notified, correct? Is there a plan or ideas on how to solve that? BTW - I don't see any connection between the problem that you describe and the problem that SCSI executes a single command at a time (host_busy <= 1). As I said, I don't think that the problem is sgp_dd (that runs with thr=8). Erez _______________________________________________ Stgt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/stgt-devel
