On Tue, 2011-11-22 at 00:24 +0100, Jörn Engel wrote: > On Mon, 21 November 2011 14:38:59 -0800, Nicholas A. Bellinger wrote: > > On Sun, 2011-11-20 at 16:29 -0500, Christoph Hellwig wrote: > > > > > Nevermind that the whole session linkage should really move to a > > > different lock ASAP anyway. > > > > I think doing this makes sense now.. I'm still finishing up a few other > > qla_tgt-3.3 related items atm, but will look at getting this separated > > out over the next days. > > Good! I'm currently doing the same in a backlevel kernel, as > contention for ha->hardware_lock can take up to 15% of our cpu time. > Having to duplicate the effort sucks, but getting regressions when > next upgrading the kernel would suck even more. So I'm happy to see > the hardware lock become a plain hardware lock again. :) > Thanks for the heads-up Joern! This has become less of an issue in recent lio-core.git/qla_tgt-3.3 code where qla_hw_data->hardware_lock is no longer re-acquired in ->check_stop_free() (uses se_cmd->cmd_kref instead), and full qla_tgt_cmd->se_cmd init is done from qla_tgt_do_work() cmwq process context w/o acquiring ->hardware_lock (less work in ATIO interrupt). We have seen an performance improvement for smaller block sizes in the 10-15% range with cmwq vs. .39 ->new_cmd_map() usage on a properly irq affinity tuned setup so far, but will be interesting to see how much of a difference spitting up session linkage from under ->hardware_lock also makes makes with cmwq. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
