lkml.org 
[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][2.5.32] CPU frequency and voltage scaling (0/4)

On 29 Aug 2002, Alan Cox wrote:
>
> One of the policies I need from the kernel is "run at the frequency I
> told you to run". Its a policy, its not the general case policy. The
> /proc file is that policy.

That's ok, but the current code DOES NOT DO THAT.

The current code has no support at all for the notion of policies, and
gives absolutely _zero_ support for it. It blindly assumes that the CPU
can (and should) run at one frequency, and as long as it does that, I
don't want it in the kernel.

> cpufreq is cpu speed control not power management policy. I agree
> entirely that most people should not be using echo "500" >/proc/... as a
> power management policy.
>
> Likewise /dev/hda is not a file system and peopel should not be using dd
> to store there files.

You've had that argument before, and it was bogus then - and it is bogus
now.

It is possible to put a filesystem on top of /dev/hda - because the block
layer is designed to allow it. It is not possible to build sane policy
upon the current frequency patches, because it is _not_ designed for
passing down the policy.

Exactly because some chips _need_ to have the policy passed down, the
lowest levels need to be able to pass it down.

It is _then_ ok to say that "if you do a 'echo 500 > /proc/cpu/freq', that
will also imply a policy of a fixed frequency". But if the frequency
setting code does not allow for any policy interface AT ALL, then it is
fundamentally broken.

That's my beef with it. We should not have "generic" interfaces that are
known to be fundamentally broken. As it is, the code - as designed - is
useless for a growing class of devices.

Think of it as a layering issue:
- user level policy
- kernel interface (possibly many - for different policies)
- low-level driver

Ok?

Now, what the current patches do is (a) one kernel interface (the
fixed-frequency one) and (b) low-level drivers.

The kernel interface is fine - it doesn't do what I think many people
might want to do, but it's simple and I agree that other policies can be
implemented with other interfaces. Fine.

But the fact that low-level drivers don't even support the notion of a
policy means that they are useless for any other interface. And I'm saying
that it's a clear design bug, and for no good reason.

Linus

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

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.053 / U:1.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site