On Sun, Dec 07, 2008 at 09:04:58AM -0600, James Bottomley wrote: > Originally I'd been promised that libata would be out of SCSI within a > year (that was when it went in). The slight problem is that having all > the features it needed, SCSI became a very comfortable host. Getting > libata out of SCSI was also made difficult by the fact that few people > cared enough to help. The only significant external problem is the size > of the stack and the slight performance penalty for SATA disks going > over SAT. Unfortunately for the latter, slight turns out to be pretty > unmeasurable, so the only hope became people who cared about > footprint ... and there don't seem to be any of those. The performance penalty is certainly measurable. It's about 1 microsecond per request extra to go from userspace -> scsi -> libata -> driver than it is to go from userspace -> scsi -> driver. If you issue 400 commands per second (as you might do with a 15k RPM SCSI drive), that's 400 microseconds. If you issue 10,000 commands per second (as you might do with an SSD), that's 10ms of additional CPU time spent in the kernel per second (or 1%). So it's insignificant overhead ... unless you have an SSD. I have asked Tejun if there's anything he wants help with to move the libata-scsi separation along, but he's not come up with anything yet. Right now, I'm investigating a technique that may significantly increase the number of requests we can do per second without rewriting the whole thing. (OK, I haven't measured the overhead of the *SCSI* layer, I've measured the overhead of the *libata* layer. I think the point here is that you can't measure the difference at a macro level unless you're sending a lot of commands.) -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
