lkml.org 
[lkml]   [2010]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [ANNOUNCE] Status of unlocked_qcmds=1 operation for .37
From
Date
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..

Any comments folks..?

--nab



\
 
 \ /
  Last update: 2010-10-30 02:07    [W:2.023 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site