From: xerofoify@gmail.com (nick)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Cpu Freq Merge with Scheduler
Date: Thu, 18 Dec 2014 13:50:52 -0500 [thread overview]
Message-ID: <5493220C.3090205@gmail.com> (raw)
In-Reply-To: <20141218132350.9524267uvvgshk1k@crashcourse.ca>
Robert,
After doing some research I found on the lkml logs and through google that the latest discussion about this on the kernel
lists was in 2013. I am curious as to where we are in terms of merging cpuidle and cpufreq into the scheduler, I known we have
a basic patch series written in 2013 but seems that's about it. We also don't seem to have any test software to test this either.
through seems there was some discussion at the plumber's conference in October of this year in Germany. Seems for my understanding
we have hit a few roadblocks.
1. We have no benchmark tools, due to power management being hard to benchmark( lots of user cases)
2. Power Management is complex and doing a best fix all solution is impossible or near impossible
3. Merging cpuidle and cpufreq into the scheduler is a long and complex issue, we need to also benchmark and test for regressions as we
are prone to error when merging these subsystems in the scheduler
4. This takes me back to my first point. we don't have have benchmark tools or a suite, therefore we shouldn't merge due to not being
able to test for bugs or regressions we cause during the merge of these two subsystems into the scheduler.
My question stands as follows have we got any farther on the above list of issues or not?
Regards Nick
On 2014-12-18 01:23 PM, Robert P. J. Day wrote:
> Quoting nick <xerofoify@gmail.com>:
>
>> Greetings Fellow Developers,
>
>> I am curious about the work going into making the kernel scheduler
>> more CPU power efficient. I have done some googling on this and
>> am curious about what how is going into the ideas/patches for this work.
>
>> Nick
>
> OFFS ... why are you asking about a clearly advanced kernel feature
> on the kernel *newbies* list? And by the way, Nick, this is another
> of your less endearing features -- your habit of posting one or two
> line posts, effectively saying, "I am interested in topic <X>, could
> everyone drop what they're doing and explain it to me in astonishing
> detail to save me the trouble of doing any work?"
>
> You've done this before -- the networking stack, BTRFS, and probably
> more. Rather than do enough research to ask *detailed* and *specific*
> questions, you instead simply request that people here explain something
> to you, and it's getting kind of tiring.
>
> Do your own research. Stop asking everyone else to do it for you.
>
> rday
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
prev parent reply other threads:[~2014-12-18 18:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 18:05 Cpu Freq Merge with Scheduler nick
2014-12-18 18:23 ` Robert P. J. Day
2014-12-18 18:50 ` nick [this message]
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=5493220C.3090205@gmail.com \
--to=xerofoify@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.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;
as well as URLs for NNTP newsgroup(s).