Message-Id: <1288396645.19406.32.camel@haakon2.linux-iscsi.org>
Date:	Fri, 29 Oct 2010 16:57:25 -0700
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Boaz Harrosh <bharrosh@...asas.com>,
	James Bottomley <James.Bottomley@...e.de>,
	Mike Anderson <andmike@...ux.vnet.ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	Vasu Dev <vasu.dev@...ux.intel.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Mike Christie <michaelc@...wisc.edu>,
	James Smart <james.smart@...lex.com>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Christoph Hellwig <hch@....de>, Tejun Heo <tj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, julia@...u.dk,
	Jeff Garzik <jeff@...zik.org>
Subject: Re: [ANNOUNCE] Status of unlocked_qcmds=1 operation for .37

<trimming the CC' list, as the last response appears to have bounced>

On Fri, 2010-10-29 at 09:50 +0200, Andi Kleen wrote:
> > I would have to agree that approach does make a bit more sense..  Now
> > can some brave soul (/me looks at ak) code another script to automate
> > this for the identified legacy LLDs cases that need push down..?
> 
> For the drivers I looked at it doesn't really make too much difference,
> I don't think there was any with a really large number of returns.
> You can see that in the diffstat for the full changes.
> 

Yep, this is a valid point.  During the push down this week, I only ran
into a handful (say ~15) overly-complex SHT->queuecommand() w more than
a few return statements.  This was also isoloated for the most part into
legacy/ancient LLDs.

> Writing another script is probably not too hard, but the problem
> is that I needed a significant amount of manual post processing
> (both the select the right files to patch and to get rid
> of misplaced newlines and some mismatches in cocci) 
> So it's not a fully automated procedure.
> 

<nod>

So I really do not have a strong preference here.  I think Boaz's
approach is a bit cleaner, but in the end I think it should not hold up
on a global push-down merge for lio-4.0.git/host_lock-less-for-37-v9.

Also, at this point I have not received any other feedback from LLD
maintainers to say "My LLD should be running in lock-less mode" or "My
LLD cannot run in lock-less mode, and needs the host_lock push down".

One additional point that was raised by jgarzik was that those LLDs
running in 'lock-less' mode may need to have their internal
->queuecommand() spinlocks converted to spin_lock_irqsave() +
spin_unlock_irqrestore().  This has already been fixed for libata
following Jeff's recommendation, but we also identified a few other
potential LLDs that may need more work.  From the last response locatd
here:

http://marc.info/?l=linux-scsi&m=128825558912565&w=2

"Ok, so originally libiscsi, fnic, and lpfc where using
spin_unlock(host->host_lock) -> spin_lock(host->host_lock)

And libsas, qla2xxx, qla4xxx where using
spin_unlock_irq(host->host_lock) -> spin_lock_irq(host->host_lock)

Just to verify, you are thinking that those *not* using spin_unlock_irq
+ spin_lock_irq() for the legacy optimization dispatch should have their
per LLD host lock converted to spin_lock_irqsave() +
spin_unlock_irqrestore(), right..?"

So I think that means an audit of locks obtained in libiscsi, fnic and
lpfc will be in to ensure they do not assume irqs have alreadby been
externally disabled for lock-less operation..

Comments folks..?

--nab


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists