On Wed, Aug 4, 2010 at 10:40 PM, Roland Dreier <[email protected]> wrote: > > > I believe this is a wrong approach for this problem. You are > > workarounding it, not solving, and introducing a bad side effect of > > additional context switch per command, so increasing its processing > > latency. It doesn't matter that it can be switched off. Linux already > > has too many magic knobs where average user for long ago get lost. > > agree ... how do we expect users to know what value to set for the > thread parameter? > > > If you want to spread requests post processing among several CPUs, you > > should consider real approaches for that: > > And furthermore, as far as I can see, the subject line of this patch is > quite misleading. It does not use multiple CPUs at all for the numbers > posted, since it creates a single kthread and moves completion > processing there (although maybe this would help with multiple targets). > > It seems the real improvement comes exactly from the increased latency: > by waiting a little while (overhead of going from completion interrupt > to kthread scheduling) before processing completions, we take fewer > interrupts because we process completions in bigger batches. > > So maybe a better solution would be something NAPI-like -- ie when a > completion occurs, schedule a tasklet that polls the CQ some number of > times, and if the CQ is not empty at the end, reschedule to tasklet to > poll the CQ again without reenabling the CQ notification... ie > adaptively go into a polling mode when the interrupt load goes up. > > But maybe this should be done higher in the block stack?
How about adding blk-iopoll support in ib_srp ? blk-iopoll is the NAPI equivalent for block devices. More information about blk-iopoll can be found here: http://lkml.org/lkml/2009/8/6/395. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
