From: Michael Tokarev <mjt@tls.msk.ru>
To: Johannes Weiner <hannes@saeurebad.de>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Dave Jones <davej@codemonkey.org.uk>
Subject: Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
Date: Fri, 21 Dec 2007 17:00:58 +0300 [thread overview]
Message-ID: <476BC71A.40806@msgid.tls.msk.ru> (raw)
In-Reply-To: <87d4t05f5a.fsf@saeurebad.de>
Johannes Weiner wrote:
[]
> I still have a bug with cpufreq when using ondemand governor as default.
>
> The performance governor, which has been the essential default until
> 1c2562459faedc35927546cfa5273ec6c2884cce, was initialized with
> fs_initcall() instead of module_init() to make sure the driver is up and
> running when the bootcode (speedstep_init in my case) calls into it.
>
> Since the above mentioned commit, other governors can also be chosen to
> be the default but they are not correctly initialized before first use
> then.
By the way, is there any real need to specify default governor at
a compile time in the first place? Performance governor (which was
the only default so far) is a very simple one (not large to consider
its size effects for embedded systems for example), and switching
governors at run time is trivial as well. What's the motivation
behind this new config option?
[]
> This migrates all governors from module_init() to fs_initcall() when
> being the default, as was already done in cpufreq_performance when it
> was the only possible choice.
Oh well. Which leads to more surprises in the future, I think...
Thanks.
/mjt
next prev parent reply other threads:[~2007-12-21 14:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-21 1:12 2.6.24-rc5-git7: Reported regressions from 2.6.23 Rafael J. Wysocki
2007-12-21 13:52 ` Johannes Weiner
2007-12-21 14:00 ` Michael Tokarev [this message]
2007-12-21 14:56 ` Johannes Weiner
2007-12-21 15:34 ` Johannes Weiner
2007-12-21 22:27 ` Rafael J. Wysocki
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=476BC71A.40806@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=akpm@linux-foundation.org \
--cc=davej@codemonkey.org.uk \
--cc=hannes@saeurebad.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox