Prev: slub crashes on dma allocations
Next: perf: fix use_browser infinite loop bug in annotate
From: Igor Stoppa on 27 May 2010 10:50
Hi,


ext Arjan van de Ven wrote:

> it's really inconvenient to have such drivers hidden in the
> architecture code; it's much more convenient for cpuidle developers
> if they're all in one place.
>

why?

> Think of it this way: you're not putting the NIC driver for your SOC in
> a architecture directory either...
>
>

That would be a separate chip, usually, which has its own driver.

The SOC has some bus interface and the arch-specific part of it, if any,
is in the arch directory.

igor

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Len Brown on 27 May 2010 21:50
On Thu, 27 May 2010, Thomas Renninger wrote:

> On Thursday 27 May 2010 04:42:31 Len Brown wrote:
> > From: Len Brown <len.brown(a)intel.com>
> ...
> > CONFIG_INTEL_IDLE=m is not recommended unless the system
> > has a method to guarantee intel_idle loads before ACPI's
> > processor_idle.

> Then it should better be declared bool instead of tristate until it
> works.

intel_idle as a module works fine, and tristate should be retained.

If user-space chooses to load intel_idle before acpi processor,
then it correctly handlees idle states and acpi
correctly yields. If user space gets them in the other order,
then user-space gets what it asked for.

The fact that a typical desktop distro load acpi-cpufreq first,
and that depends on the acpi processor driver should not prohibit
intel_idle from being modular.

Indeed, intel_idle has every right to be moduler on a system
where CONFIG_ACPI=n...

> > This driver does not yet know about cpu online/offline
> > and thus will not yet play well with cpu-hotplug.

> What means does not play well yet, suspend or manually offlining a core
> will eventually (for sure?) hang the machine?

It means less power savings savings than optimal
for processors not present at module load time.

> If this is known broken, should this already be spread through
> linux-next?

If you know somebody with a system that supports CPU hot-add
on one of the processors supported by intel_idle, and they
are willing to test linux-next, please have them contact me.

thanks,
-Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Len Brown on 28 May 2010 13:40
On Fri, 28 May 2010, Thomas Renninger wrote:

> On Friday 28 May 2010 03:44:16 Len Brown wrote:
> > On Thu, 27 May 2010, Thomas Renninger wrote:
> ...
> > > > This driver does not yet know about cpu online/offline
> > > > and thus will not yet play well with cpu-hotplug.

> I thought this is also about soft on/offlining.

Right, the driver is ignorant of soft on/offlining,
but doesn't break soft on/offlining.
So rather than un-registering from cpuidle on
an offline event and re-registering on an on-line event,
it just stays registered.

The vast majority of on/offline is suspend to ram,
and this works just fine there.

Soft off-lining is somewhat broken for power management
independent of this driver, of course. As it uses only C1
it can negatively impact the ability of the online processors
to save power and enter turbo mode...

> > > What means does not play well yet, suspend or manually offlining a
> > > core will eventually (for sure?) hang the machine?
> >
> > It means less power savings savings than optimal
> > for processors not present at module load time.

> Ok, not really sever...

Agreed, not severe.

> > > If this is known broken, should this already be spread through
> > > linux-next?
> >
> > If you know somebody with a system that supports CPU hot-add
> > on one of the processors supported by intel_idle, and they
> > are willing to test linux-next, please have them contact me.

> Real CPU hotplug is broken with acpi processor driver as well,
> eventually it got addressed lately. Anyway, not sever...

Yeah, if I had a system with real cpu hotplug, I'd go ahead
and test it -- but I've never even seen one.

thanks,
-Len Brown, Intel Open Source Technology Center

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: slub crashes on dma allocations
Next: perf: fix use_browser infinite loop bug in annotate