> 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? - R. -- Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- 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
