Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

[Paul E. McKenney]

On Sun, Jan 28, 2007 at 03:30:05PM -0800, Andrew Morton wrote:
> On Sun, 28 Jan 2007 14:47:56 -0800
> "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> 
> > > If we use the process freezer, these bugs all get automatically fixed,
> > > and we get to remove the existing locking, and we don't need to think
> > > about it any more.
> > 
> > The idea being to essentially suspend the system to RAM, remove the
> > CPU and then unsuspend it?  Seems like quite high overhead -- or am
> > I misunderstanding the proposal?
> 
> The process freezer basically wakes up all threads in the machine and makes
> them go to sleep in a specific place, so they're all in a known state. 
> kernel threads are also captured, via their open-coded polling call to
> try_to_freeze().
> 
> The machine suspend code uses the process freezer, as does kprobes.  The
> freezer isn't tied to suspend or to power management.
> 
> The freezer does have potential to be expensive if used frequently and if
> there are many threads.  But I don't think anyone has looked at optimising
> it.  For example, there are certain places in the kernel where threads
> commonly sleep (eg, select()).  We know that this is a safe place to sleep
> wrt (at least) CPU hotplug, so there's not really a need to wake those
> processes up.  Perhaps something could be done with that observation...
> 
> But first we'd need to demonstrate that we actually have a problem.

Fair enough -- though if it is a goal to remove CPUs from systems with
realtime workloads, I can assure you that we do have a problem.

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