On Tue, 2013-08-20 at 23:48 -0700, Christoph Hellwig wrote: > On Tue, Aug 20, 2013 at 01:38:04PM -0700, Nicholas A. Bellinger wrote: > > <yawn>, I only care about the performance against upstream code, so that > > would mean scsi_debug here. Typically the onus of demonstrating a > > performance improvement is on the patch submitter (eg: not the > > reviewer). > > Do you really care? If the patchset introduced a lot of code or > ugliness I might agreee to your above statement, but it actually > makes the code more obvious, simpler and also fixes some small issues > so I don't think we'll need an exact performance improvement to justify > it. Of course not. I'm curious 1) how fast Bart has a SCSI client going using scsi_request_fn(), and if it's a measurable difference 2) what that difference is. > > > But it would be at least useful to know the actual benefit with results > > as an incremental step, short of avoiding this code entirely for > > scsi-mq. > > I don't think you can avoid the device put/get entirely for that case. > I've been looking over the mq code a bit more lately, and in a few > places it just seems to try to cut a few too many corners. Yes, it's a prototype! > To get it out of the prototype status we'll need to make sure all edge cases > are handled correctly. > Ohhh, yes. I'm not claiming that it's anything beyond a very early alpha at this stage, and have no plans for a mainline push anytime before 2014 arrives, before scsi_error.c supports per-device context recovery, or before hell freezes over. Which ever comes first.. ;) --nab -- 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
