From: Thomas Renninger <mail@renninger.de>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: cpufreq@lists.linux.org.uk,
Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: ondemand governor and passive cooling broken?
Date: Thu, 25 Aug 2005 12:30:03 +0200 [thread overview]
Message-ID: <430D9DAB.6050502@renninger.de> (raw)
In-Reply-To: <88056F38E9E48644A0F562A38C64FB600588ED10@scsmsx403.amr.corp.intel.com>
Pallipadi, Venkatesh wrote:
>
>
>>-----Original Message-----
>>From: Thomas Renninger [mailto:mail@renninger.de]
>>Sent: Saturday, August 20, 2005 9:49 PM
>>To: Dominik Brodowski
>>Cc: cpufreq@lists.linux.org.uk; Pallipadi, Venkatesh
>>Subject: Re: ondemand governor and passive cooling broken?
>>
>>Hi,
>>
>>This makes ondemand governor aware of thermal limits.
>>The policy was buffered and new policy values never reached
>>the governor.
>
> I don't think there is an issue with buffering here.
> This_dbs_info->cur_policy is a pointer to the cpufreq policy (and not
> allocated by ondemand governor). So, any change to max/min in cpufreq
> should be automatically getting reflected. Atleast that was the intent
> with having policy pointer. If it is not happening then that should be a
> bug. I don't think that this memcpy is required here.
>
You are right. I tried to reproduce this problem with a powernow-k8 machine
and thermal cooling worked just fine.
>>I just used the cpufreq_get_policy call every time the load is checked,
>>maybe the new policy should be made available via notifier as
>>it is done
>>for the cur_freq in the userspace governor?
>>If this sounds reasonable I can come up with a bigger patch on Monday.
>>
>>However, thermal cooling still does not always work right:
>>
>> - Sometimes the limit is not decreased correctly in polling
>>frequency time
>> (I saw it at max for more than 20 secs, polling freq 5
>>secs, passive tp exceeded).
>> Strange enough, that seems to happen only in rare cases.
>> - I also saw the limit stuck at lowest frequency even after
>>getting back in
>> normal temperature zones.
>
> I think we need to do some more things to intergrate cpufreq and thermal
> cooling. Especially in relation to polling frequency. Probably, ondemand
> governor should slow down its polling interval to something higher than
> thermal polling frequency as soon as it notices the passive cooling is
> on.
Don't know. I will try to get a speedstep-centrino machine and have a look
whether this makes a difference and also play around a bit with thermal polling freq
and ondemand configs. Do you think this could be a driver specific problem?
Thanks,
Thomas
next prev parent reply other threads:[~2005-08-25 10:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-24 19:09 ondemand governor and passive cooling broken? Pallipadi, Venkatesh
2005-08-25 10:30 ` Thomas Renninger [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-08-03 18:17 Thomas Renninger
2005-08-16 9:48 ` Dominik Brodowski
2005-08-21 4:48 ` Thomas Renninger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=430D9DAB.6050502@renninger.de \
--to=mail@renninger.de \
--cc=cpufreq@lists.linux.org.uk \
--cc=linux@dominikbrodowski.net \
--cc=venkatesh.pallipadi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.