Re: [PATCH] qla2xxx: Resolved a performance issue in interrupt handler

Anirban Chakraborty
2009-06-10T18:29:42Z

On Jun 10, 2009, at 9:18 AM, Matthew Wilcox 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@qlogic.com] 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.
>
One way to confirm this would be to run several times and see what
comes up. If we get consistently same order of magnitude difference
then we'd know for sure. The thing to note here is the overall
difference in database cycle %s which is more than the margin of error.
Thanks,
Anirban

>>> ======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
>>> 0.4686 __sigsetjmp 0.4580 __sigsetjmp
>>> 0.4043 __blockdev_direct_IO 0.4206 __switch_to
>>> 0.3894 __switch_to 0.4169 __blockdev_direct_IO
>>> 0.3878 rb_get_reader_page 0.3907 scsi_request_fn
>>> 0.3762 task_rq_lock 0.3776 task_rq_lock
>>> 0.3729 scsi_request_fn 0.3701 rb_get_reader_page
>>> 0.3696 __list_add 0.3664 __list_add
>>> 0.3168 <bash> 0.3664 copy_user_generic_string
>>> 0.3135 try_to_wake_up 0.3122 lock_timer_base
>>> 0.2921 ring_buffer_consume 0.2972 ring_buffer_consume
>>> 0.2822 lock_timer_base 0.2879 <bash>
>>> 0.2624 memset_c 0.2785 aio_complete
>>> 0.2607 aio_complete 0.2524 blk_queue_end_tag
>>> 0.2508 copy_user_generic_string 0.2468 try_to_wake_up
>>> 0.2294 qla2x00_process_completed_re 0.2430 tcp_sendmsg
>>> 0.2294 tcp_sendmsg 0.2393 mod_timer
>>> 0.2211 kfree 0.2374
>>> qla2x00_process_completed_re
>>> 0.2195 memmove 0.2355 memset_c
>>> 0.2195 blk_queue_end_tag 0.2225 e1000_xmit_frame
>>> 0.2145 scsi_softirq_done 0.2094 generic_make_request
>>> 0.2145 mod_timer 0.2075 scsi_device_unbusy
>>> 0.2129 generic_file_aio_read 0.2056 kref_get
>>> 0.2096 kref_get 0.2056 mempool_free
>>> 0.1997 e1000_xmit_frame 0.2038 qla2xxx_queuecommand
>>> 0.1997 scsi_device_unbusy 0.2000 kfree
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-
>> scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> 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."