On Fri, Nov 17, 2006 at 08:51:03PM -0800, Andrew Morton wrote:
> On Fri, 17 Nov 2006 23:33:45 -0500 (EST)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 17 Nov 2006, Paul E. McKenney wrote:
> >
> > > > Perhaps a better approach to the initialization problem would be to
> > > > assume
> > > > that either:
> > > >
> > > > 1. The srcu_struct will be initialized before it is used, or
> > > >
> > > > 2. When it is used before initialization, the system is running
> > > > only one thread.
> > >
> > > Are these assumptions valid? If so, they would indeed simplify things
> > > a bit.
> >
> > I don't know. Maybe Andrew can tell us -- is it true that the kernel runs
> > only one thread up through the time the core_initcalls are finished?
>
> I don't see why - a core_initcall could go off and do the
> multithreaded-pci-probing thing, or it could call kernel_thread() or
> anything. I doubt if any core_initcall functions _do_ do that, but there
> are a lot of them.
>
> > If not, can we create another initcall level that is guaranteed to run
> > before any threads are spawned?
>
> It's a simple and cheap matter to create a precore_initcall() - one would
> need to document it carefully to be able to preserve whatever guarantees it
> needs.
>
> However by the time the initcalls get run, various thing are already
> happening: SMP is up, the keventd threads are running, the CPU scheduler
> migration threads are running, ksoftirqd, softlockup-detector, etc.
> keventd is the problematic one.
>
> So I guess you'd need a new linker section and a call from
> do_pre_smp_initcalls() or thereabouts.
Hmmm... OK then, for the moment, I will stick with the current checks
in the primitives. Not that I particularly like the "bulking up" of
srcu_read_lock() and srcu_read_unlock() -- but if the super-fast
version is needed, it can easily be provided either within the
confines of the subsystem that needs it, or as yet another set of
RCU-like primitives. Hopefully this latter option can be avoided!
BTW, the reason for the hardluckref is that I don't want to inflict a
failure return from srcu_read_lock() on you guys. The non-blocking
synchronization community has repeatedly made that sort of mistake,
and I have no intention of letting it propagate any further. ;-)
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
