The problem statement indicates affinity issue but IOPOLL implementation had issues too. 1. IOPOLL budget passed in the callback is not being honored. This was the root cause where the driver kept polling in softirq. 2. The interrupts kept coming even when IOPOLL is scheduled. So we needed to fix EQ rearming. I think, choosing CPU affinity internally by driver is not right thing to do. For setting IRQ affinity you need to have holistic view of the system and better done by external entity which has heuristics of all the varied workloads on the system. -----Original Message----- From: Hannes Reinecke [mailto:hare@xxxxxxx] Sent: Monday, December 14, 2015 8:54 PM To: Jitendra Bhivare; linux-scsi@xxxxxxxxxxxxxxx; michaelc@xxxxxxxxxxx Subject: Re: [PATCH 6/9] be2iscsi: Fix IOPOLL implementation On 12/14/2015 07:11 AM, Jitendra Bhivare wrote: > From: Jitendra <jitendra.bhivare@xxxxxxxxxxxxx> > > OS not responding when running 2 port traffic on 72 CPUs system. > > be2iscsi IRQs gets affined to CPU0 when irqbalancer is disabled. > be_iopoll processing completions in BLOCK_IOPOLL_SOFTIRQ hogged CPU0. > > 1. Use budget to exit the polling loop in beiscsi_process_cq. > 2. Rearming of EQ is done only after iopoll completes. > > Signed-off-by: Jitendra <jitendra.bhivare@xxxxxxxxxxxxx> > --- > drivers/scsi/be2iscsi/be_cmds.c | 2 +- > drivers/scsi/be2iscsi/be_iscsi.c | 2 +- > drivers/scsi/be2iscsi/be_main.c | 91 +++++++++++++++++++++----------------- > drivers/scsi/be2iscsi/be_main.h | 5 +- > 4 files changed, 56 insertions(+), 44 deletions(-) > Hmm. Not sure if I agree with this. Doesn't the be2iscsi driver set the cpu affinity internally? If not, wouldn't that be the better solution? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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
