[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0610281651340.3849@g5.osdl.org>
Date: Sat, 28 Oct 2006 16:55:42 -0700 (PDT)
From: Linus Torvalds <torvalds@...l.org>
To: "Adam J. Richter" <adam@...drasil.com>
cc: akpm@...l.org, bunk@...sta.de, greg@...ah.com,
linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz,
matthew@....cx, pavel@....cz, shemminger@...l.org
Subject: Re: [patch] drivers: wait for threaded probes between initcall levels
On Sun, 29 Oct 2006, Adam J. Richter wrote:
>
> If only calls to execute_in_parallel nest, your original
> implementation would always deadlock when the nesting depth exceeds
> the allowed number of threads, and also potentially in some shallower
> nesting depths given a very unlucky order of execution. In your
> original message, you mentioned allowing the parallelism limit to be
> set as low as 1.
No, I'm saying that nesting simply shouldn't be _done_. There's no real
reason. Any user would be already either parallel or doesn't need to be
parallel at all. Why would something that already _is_ parallel start
another parallel task?
IOW, what I was trying to say (perhaps badly) is that "nesting" really
isn't a sensible operation - you'd never do it. You'd do the "startup" and
"shutdown" things at the very highest level, and then in between those
calls you can start a parallel activity at any depth of the call stack,
but at no point does it really make sense to start it from within
something that is already parallel.
Hmm?
(Btw, you do seem to have some strange email setup that doesn't allow me
to email you directly, I just get a bounce. I'll try again, but you'll
probably pick this up on linux-kernel rather than in your private
mailbox).
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