On Wed, Jun 10, 2009, wrote: > On Wed, Jun 10, 2009 at 09:09:14AM -0700, Anirban Chakraborty wrote: > > > > On Jun 10, 2009, at 8:52 AM, Styner, Douglas W wrote: > >> Anirban Chakraborty [mailto:anirban.chakraborty@xxxxxxxxxx] write: > >>> > >>> You got it right. Basically we are doing: > >>> 1. baseline scsi-misc + earlier patch > >>> 2. baseline scsi-misc + this patch > >>> And then compare 1 and 2. > >> > >> Results are as follows: > >> Total interrupts are down slightly (-0.8%), QLA interrupts are flat > >> (-0.1%) Cycles for qla2xxx_intr_handler up from .77% to .92%. > > > > So, it looks like using spin_lock_irqsave is doing a better job than > > globally disabling the sharing of the interrupt via IRQF_DISABLED. > > The margin of error for this setup is about 0.3% for the performance > as a whole. I don't know what the margin of error is for the number > of cycles consumed by a given function, but I would suspect it's > significantly higher than the 0.15% difference seen. > > >> ======oprofile CPU_CLK_UNHALTED for top 30 functions > >> Cycles% 2.6.30-rc6_scsi-misc_0001 Cycles% 2.6.30-rc6_scsi-misc_irqf-d > >> 68.1402 <database> 66.1875 <database> > >> 0.9125 qla24xx_start_scsi 0.9552 qla24xx_start_scsi > >> 0.8729 __schedule 0.9272 __schedule > >> 0.7739 qla24xx_intr_handler 0.9178 qla24xx_intr_handler > >> 0.7161 kmem_cache_alloc 0.7963 kmem_cache_alloc That's a curious observation... I'm just trying to understand the numbers here, but, are we sure that this spin_lock() -> spin_lock_irqsave() conversion is in fact the mitigating factor. Thanks, AV -- 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
