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" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
