[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFx8=AszAeeJnSXnOsJKUhx3JjGJko1XiOKYWWRWiUE+SQ@mail.gmail.com>
Date: Fri, 21 Mar 2014 12:32:17 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Joseph Salisbury <joseph.salisbury@...onical.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
James Bottomley <JBottomley@...allels.com>,
Nagalakshmi.Nandigama@....com, Sreekanth.Reddy@....com,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ubuntu Kernel Team <kernel-team@...ts.ubuntu.com>,
Linux SCSI List <linux-scsi@...r.kernel.org>,
Tomas Henzl <thenzl@...hat.com>
Subject: Re: please fix FUSION (Was: [v3.13][v3.14][Regression] kthread:makekthread_create()killable)
On Fri, Mar 21, 2014 at 11:34 AM, Oleg Nesterov <oleg@...hat.com> wrote:
>
> Yes, it seems that it actually needs > 30 secs. It spends most of the time
> (30.13286 seconds) in [..]
So how about taking a completely different approach:
- just say that waiting for devices in the module init sequence for
over 30 seconds is really really wrong.
- make the damn mptsas driver just register the controller from the
init sequence, and then do device discovery asynchronously.
The ATA layer does this correctly: it synchronously finds each host,
but then it does
/* perform each probe asynchronously */
for (i = 0; i < host->n_ports; i++) {
struct ata_port *ap = host->ports[i];
async_schedule(async_port_probe, ap);
}
and I really think SCSI drivers should do the same if they have this
kind of "ports can take forever to probe" behavior.
What would be the equivalent magic to do this for SCSI? Could we just
make something like scsi_probe_and_add_lun() just always do this, the
same way ata_host_register() does it?
Linus
--
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