On Jun 9, 2009, at 1:40 PM, James Bottomley wrote:
On Tue, 2009-06-09 at 13:34 -0700, Anirban Chakraborty wrote:
On Jun 9, 2009, at 12:32 PM, James Bottomley wrote:
On Tue, 2009-06-09 at 11:42 -0700, Anirban Chakraborty wrote:
Reverted back a change from spin_lock to spin_lock_irq* that was
causing
the cycle times to go up.
The patch is based on scsi-misc-2.6.
Some more explanation of this would be greatly appreciated. The
cause
looks to be that holding off interrupts in the isr could potentially
reduce latency (caused by taking a different interrupt while holding
the
hardware lock) and increase the chance of coalescing (by holding off
interrupts). However, if that's the case, possibly using an
IRQF_DISABLED isr rather than going back to spin_lock_irqsave()
would be
a better fix?
The primary cause is, as you mentioned, the contention for the
hardware lock in the isr.
I'll check it with IRQF_DISABLED too. However, I was wondering if
there is any additional savings if we use IRQF_DISABLED vs. using the
spin_lock_irqsave. In the former case, probably we'd enter the isr
with interrupts disabled and in the latter case it would be done upon
entering the isr.
It depends what the root cause is ... if it's really latency
introduced
by other interrupts, then IRQF_DISABLED might be the better course.
If
it's purely interrupt problems in the spin locked critical sections,
then spin_lock_irq might be the better solution ... what would be
useful
is to have the test rig at intel which turned up the problem see what
happens to the results for each case.
James
Earlier, I have seen that when IRQ's are shared across multiple
controllers and if the first one to register (among shared
controllers) does not disable the IRQ with IRQF_DISABLED flag,then
irrespective of the IRQ registration from other controllers, the IRQ
will be enabled by default. With this behavior and qla2xxx sharing the
IRQ, just disabling the IRQ may not be sufficient.
Giridhar.M.B
--
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
--
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
