Re: bnx2i kthread madness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2011-09-28 at 10:47 -0700, James Bottomley wrote:
> On Wed, 2011-09-28 at 10:29 -0700, Eddie Wai wrote:
> > On Wed, 2011-09-28 at 08:05 -0700, Peter Zijlstra wrote:
> > > Hi,
> > > 
> > > I accidentally looked at all kthreads in existence on my system and
> > > found I had:
> > > 
> > > [iscsi_eh]
> > > [bnx2i_thread/0]
> > > [bnx2i_thread/1]
> > > [bnx2i_thread/2]
> > > [bnx2i_thread/3]
> > > [bnx2i_thread/4]
> > > [bnx2i_thread/5]
> > > [bnx2i_thread/6]
> > > [bnx2i_thread/7]
> > > [bnx2i_thread/8]
> > > [bnx2i_thread/9]
> > > [bnx2i_thread/10]
> > > [bnx2i_thread/11]
> > > [bnx2i_thread/12]
> > > [bnx2i_thread/13]
> > > [bnx2i_thread/14]
> > > [bnx2i_thread/15]
> > > [bnx2i_thread/16]
> > > [bnx2i_thread/17]
> > > [bnx2i_thread/18]
> > > [bnx2i_thread/19]
> > > [bnx2i_thread/20]
> > > [bnx2i_thread/21]
> > > [bnx2i_thread/22]
> > > [bnx2i_thread/23]
> > > 
> > > This left me wondering why, because I most certainly am not using iSCSI.
> > > I don't even know why its enabled in my .config (and it won't be long). 
> > > 
> > > Please fix this muck to not create useless threads.
> > 
> > Hello Peter,
> > 
> > Point noted.  In the current bnx2i driver, one kthread is created per
> > cpu core upon module init (and destroyed upon module exit).  The
> > kthreads are meant only to improve I/O performance when iSCSI is
> > employed.  Otherwise, I agree that they should not exist.
> 
> So if I look at the code, you seem to be trying to direct outbound
> commands via the CPU specified in the request?  I assume this is because
> we need to access the data to generate things like the checksum, in
> which case the command data needs to be CPU hot in the outbound path?
> (although I thought the bnx2 had a hardware engine that can do this).
The design goal was to align the cmd completions to the cmd request cpu
so we can take advantage of not only the cpu cache content but also to
complete the I/Os in parallel (instead of how we did it previously in
the bh serially).  From our test environment, we were able to see a
noticeable performance boost on IOPS across small I/Os.

> If we genuinely need to do something like this, the interface
> work_on_cpu() was defined for something like this purpose.
Not familiar with work_on_cpu(), let me see how this can be used
instead.  Thanks.
> 
> James
> 
> 
> --
> 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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux