userspace not supported for longrun?

userspace not supported for longrun?

[Wayne Wylupski]

Hello,

I've been tracking down an issue with using Fedora Core 2 on a 
Transmeta Crusoe TM5800 and it appears a userspace governor is not 
supported by cpufreq (the longrun scaling driver has a .setpolicy, 
which prevents the userspace governor from being set).

Could someone please explain if this is by choice or a bug?  If it's 
the latter, could someone explain why, since the CPU itself supports 
different frequencies?

Thank you,

Wayne Wylupski

Re: userspace not supported for longrun?

[Bruno Ducrot]

On Mon, May 31, 2004 at 11:40:26PM -0400, Wayne Wylupski wrote:
> Hello,
> 
> I've been tracking down an issue with using Fedora Core 2 on a 
> Transmeta Crusoe TM5800 and it appears a userspace governor is not 
> supported by cpufreq (the longrun scaling driver has a .setpolicy, 
> which prevents the userspace governor from being set).
> 
> Could someone please explain if this is by choice or a bug?  If it's 
> the latter, could someone explain why, since the CPU itself supports 
> different frequencies?
> 

It's by choice.  Even though there exist some algo. for which it's seems
there are better choice over the longrun facilities in order to switch
automatically the frequency of the processor, it's hard to get those
algo. to mainline mostly due to some kind of patent issues
apparently.  So for now the longrun driver do not have the facilities to
make what you request.  Would be fine perhaps to add that, but I'm
not sure it's in a high priority item for now.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: userspace not supported for longrun?

[Wayne Wylupski]

> It's by choice.  Even though there exist some algo. for which it's seems
> there are better choice over the longrun facilities in order to switch
> automatically the frequency of the processor, it's hard to get those
> algo. to mainline mostly due to some kind of patent issues
> apparently.  So for now the longrun driver do not have the facilities to
> make what you request.  Would be fine perhaps to add that, but I'm
> not sure it's in a high priority item for now.

Thank you.  The issue is that Fedora Core 2 ships with 'cpuspeed' as a
service, which fails on machines with Crusoe chips because it assumes
there's a userspace governor without first checking whether there it is
available.

Would it really violate patents if the userspace governor were allowed
to work along the existing policies ("powersave" and "performance")?  Or is
it that
the use of 'cpuspeed' might violate the patent?  Please help me understand
this,
because I'm going to try to recommend how FC2 should support Crusoe and
processors with longrun support.

If there's an existing e-mail, memo, or document which explains this, I
would be
read and work with it.  The existing documentation does not cover this.

Thanks,
Wayne Wylupsxki

Re: userspace not supported for longrun?

[Bruno Ducrot]

On Tue, Jun 01, 2004 at 07:52:05PM -0400, Wayne Wylupski wrote:
> > It's by choice.  Even though there exist some algo. for which it's seems
> > there are better choice over the longrun facilities in order to switch
> > automatically the frequency of the processor, it's hard to get those
> > algo. to mainline mostly due to some kind of patent issues
> > apparently.  So for now the longrun driver do not have the facilities to
> > make what you request.  Would be fine perhaps to add that, but I'm
> > not sure it's in a high priority item for now.
> 
> Thank you.  The issue is that Fedora Core 2 ships with 'cpuspeed' as a
> service, which fails on machines with Crusoe chips because it assumes
> there's a userspace governor without first checking whether there it is
> available.

Well, I assume it's for a laptop, and I assume you can detect more or
less if the AC is plugged or not.  Then all you have to do is to change
between 'powersave' and 'performance' via a little shell script.  For
example, if you have ACPI, it's should be easy to do so with acpid.


> Would it really violate patents if the userspace governor were allowed
> to work along the existing policies ("powersave" and "performance")?  Or is
> it that
> the use of 'cpuspeed' might violate the patent?  Please help me understand
> this,
> because I'm going to try to recommend how FC2 should support Crusoe and
> processors with longrun support.

cpuspeed might violate a patent but I am not sure at 100% (changing
frequency in a feedback loop is more or less patented IIRC).
But that not exactly the trouble.  I doubt that cpuspeed
is better than longrun in order to save more power anyway.

The stuff I'm thinking about have to be done in-kernel as another
governor, not userspace stuff.

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: userspace not supported for longrun?

[Dominik Brodowski]

On Tue, Jun 01, 2004 at 07:52:05PM -0400, Wayne Wylupski wrote:
> Thank you.  The issue is that Fedora Core 2 ships with 'cpuspeed' as a
> service, which fails on machines with Crusoe chips because it assumes
> there's a userspace governor without first checking whether there it is
> available.
> 
> Would it really violate patents if the userspace governor were allowed
> to work along the existing policies ("powersave" and "performance")?

No, that's a purely technical issue: The Crusoe chip can only be set to a
_frequency range_, and the chip itself (actually, the Code Morphing
Software) decides which actual frequency is best for the current workload.

So, cpufreq governors do not work on such "frequency range" systems. It is
an API mis-design [by me, I have to admit] that the file where the longrun
policy is set is named the same: what you select there is the in-chip
priority, which influences the in-chip decision on what frequency to run.

> because I'm going to try to recommend how FC2 should support Crusoe and
> processors with longrun support.

FC2 should not try to run cpuspeed on crusoe processors, but

select "powersave" as policy [a.k.a scaling_governor] when on battery, and
select "performance" as policy [a.k.a scaling_governor] when on AC. 

That's all.

> If there's an existing e-mail, memo, or document which explains this, I
> would be
> read and work with it.  The existing documentation does not cover this.

Section 2 of Documentation/cpu-freq/user-guide.txt at least has some hints.

	Dominik

Re: userspace not supported for longrun?

[Bruno Ducrot]

On Wed, Jun 02, 2004 at 02:19:17PM +0200, Dominik Brodowski wrote:
> On Tue, Jun 01, 2004 at 07:52:05PM -0400, Wayne Wylupski wrote:
> > Thank you.  The issue is that Fedora Core 2 ships with 'cpuspeed' as a
> > service, which fails on machines with Crusoe chips because it assumes
> > there's a userspace governor without first checking whether there it is
> > available.
> > 
> > Would it really violate patents if the userspace governor were allowed
> > to work along the existing policies ("powersave" and "performance")?
> 
> No, that's a purely technical issue: The Crusoe chip can only be set to a
> _frequency range_, and the chip itself (actually, the Code Morphing
> Software) decides which actual frequency is best for the current workload.

You can run a crusoe chip on a fixed frequency.

Some people also think that on some situation, the longrun will consume
more power than their algorithm (search for "vertigo OSDI2002", I don't
remmeber the exact link) for an example.

Of course the userspace stuff is completely useless anyway.

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: userspace not supported for longrun?

[Wayne Wylupski]

Thank you everyone.  It's clear that cpuspeed is the wrong service for
Crusoe chips, and
other tools & services should be used instead.  I believe my laptop supports
ACPI, but I'll
also check out longrun and cpufreqd as well.

Wayne

Re: userspace not supported for longrun?

[Francesco Poli]

[-- Attachment #1.1: Type: text/plain, Size: 787 bytes --]

On Wed, 2 Jun 2004 14:19:17 +0200 Dominik Brodowski wrote:

> > because I'm going to try to recommend how FC2 should support Crusoe
> > and processors with longrun support.
> 
> FC2 should not try to run cpuspeed on crusoe processors, but
> 
> select "powersave" as policy [a.k.a scaling_governor] when on battery,
> and select "performance" as policy [a.k.a scaling_governor] when on
> AC. 
> 
> That's all.

You can easily do this (and much more) with Cpufreqd:
http://sourceforge.net/projects/cpufreqd/

-- 
             |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |        Key fingerprint = | and, all of a sudden, boom!
     Poli    | C979 F34B 27CE 5CD8 DC12 |         -- from APT HOWTO,
             | 31B5 78F4 279B DD6D FCF4 |             version 1.8.0

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

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

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: userspace not supported for longrun?

[Dominik Brodowski]

To clarify some things:

On Mon, May 31, 2004 at 11:40:26PM -0400, Wayne Wylupski wrote:
> I've been tracking down an issue with using Fedora Core 2 on a 
> Transmeta Crusoe TM5800 and it appears a userspace governor is not 
> supported by cpufreq (the longrun scaling driver has a .setpolicy, 
> which prevents the userspace governor from being set).

.setpolicy drivers prevent _all_ governors from being set. They don't need
governors, as they are set to a 
- frequency range
and a - policy , e.g. a in-hardware [or microcode] algorithm which decides
on what speed the CPU should run at within the range specified above.

> Could someone please explain if this is by choice or a bug?  If it's 
> the latter, could someone explain why, since the CPU itself supports 
> different frequencies?
... and the CPU switches between these different frequencies itself, as long
as they are within the frequency range.

	Dominik