Re: CPU local things [was Re: Nested suspends; messages vs. states]

[Nigel Cunningham <ncunningham-3EexvZdKGZRWk0Htik3J/w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

Hi Nathan.

On Fri, 2005-03-25 at 04:14, Nathan Lynch wrote:
> > > > Become more componentized. We need a better way to represent optional
> > > > features of any device, but in particular CPUs. We should never be calling
> > > > it directly; we should be looping over the feature drivers bound to a 'CPU
> > > > Driver' and suspending them.
> > >
> > > Actually, no.
> > >
> > > mtrr's are cpu local. That means they need to be handled by CPU
> > > hotplug framework. I guess we should just drop them from "normal"
> > > device trees, and create something per-CPU.
> > 
> > Sorry, it was late and that explanation sucked.
> > 
> > - Every CPU has a set of optional features that it supports.
> > 
> > - MTRRs are an optional feature that a CPU may support.
> > 
> > - When the MTRR driver is loaded, a data structure should be allocated for
> >   each CPU and added to a list.
> > 
> > - The list that the per-CPU MTRR data structure is added to could be part
> >   of a 'CPU driver'.
> > 
> > - We should be looping over the set of optional features that a CPU
> >   supports to suspend/resume them, rather than calling them directly.
> 
> Don't sysdev_suspend and sysdev_resume do this already?

I guess you missed part of the context of this discussion. MTRR sysdev
suspend and resume work fine for one CPU, but there's a potential SMP
deadlock. For Suspend2, MTRR sysdev support was removed a number of
months ago, and tied in to CPU state saving and restoring. This
addressed the deadlock, correctly, I believe.

Hope this helps.

Nigel

> > > Perhaps plain old notification list is enough for this one.
> > 
> > It's possible, but notification lists present some problems. Like the fact
> > they use a hard-coded set of events in a global header file. They are good
> > only for a certain set of events.
> > 
> > It's damn simple to create a struct type for CPU features and a method
> > contained in each one for cpu offline/online. I would suggest adding a
> > list_head to struct cpu (include/linux/cpu.h) called 'features', then
> > having things like MTRR add themselves to that list.
> 
> Why is the existing sysdev auxiliary driver support not sufficient?
> Last time I checked, cpufreq uses it for this kind of purpose.
> 
> 
> Nathan
> 
> ______________________________________________________________________
> _______________________________________________
> linux-pm mailing list
> linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
> http://lists.osdl.org/mailman/listinfo/linux-pm
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]