From: Arjan van de Ven <arjan@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
lenb@kernel.org, rjw@rjwysocki.net,
Eliezer Tamir <eliezer.tamir@linux.intel.com>,
Chris Leech <christopher.leech@intel.com>,
David Miller <davem@davemloft.net>,
rui.zhang@intel.com, jacob.jun.pan@linux.intel.com,
Mike Galbraith <bitbucket@online.de>,
Ingo Molnar <mingo@kernel.org>,
hpa@zytor.com, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH 3/7] idle, thermal, acpi: Remove home grown idle implementations
Date: Wed, 20 Nov 2013 09:23:52 -0800 [thread overview]
Message-ID: <528CF028.2040002@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1311201814410.30673@ionos.tec.linutronix.de>
On 11/20/2013 9:23 AM, Thomas Gleixner wrote:
> On Wed, 20 Nov 2013, Arjan van de Ven wrote:
>
>> On 11/20/2013 8:04 AM, Peter Zijlstra wrote:
>>> This does not fully preseve existing behaviour in that the generic
>>> idle cycle function calls into the normal cpuidle governed idle
>>> routines and should thus respect things like QoS parameters and the
>>> like.
>>
>>
>> NAK on the powerclamp side.
>>
>> powerclamp MUST NOT do that....
>> it is needed to go to the deepest state no matter what
>> (this is for when your system is overheating. there is not a lot of choice
>> here... alternative is an emergency reset that the hardware does for safety)
>
> So that whole machinery falls apart when the thing which is running on
> that hot core is a while(1) loop with a higher or equal FIFO priority
> than this thread. Even if you'd run at prio 99, then there is no
> guarantee that the cpu hog does not run with prio 99 as well and due
> to FIFO and being on the CPU it's not going to let you on.
the idea was to at least give people who know what they're doing a chance to run
next prev parent reply other threads:[~2013-11-20 17:23 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-20 16:04 [PATCH 0/7] Cure some vaux idle wrackage Peter Zijlstra
2013-11-20 16:04 ` [PATCH 1/7] x86, acpi, idle: Restructure the mwait idle routines Peter Zijlstra
2013-11-20 16:04 ` [PATCH 2/7] sched, preempt: Fixup missed PREEMPT_NEED_RESCHED folding Peter Zijlstra
2013-11-21 8:25 ` Peter Zijlstra
2013-11-20 16:04 ` [PATCH 3/7] idle, thermal, acpi: Remove home grown idle implementations Peter Zijlstra
2013-11-20 16:40 ` Arjan van de Ven
2013-11-20 16:59 ` Peter Zijlstra
2013-11-20 17:23 ` Thomas Gleixner
2013-11-20 17:23 ` Arjan van de Ven [this message]
2013-11-20 17:55 ` Thomas Gleixner
2013-11-20 18:21 ` Arjan van de Ven
2013-11-20 19:38 ` Thomas Gleixner
2013-11-20 22:08 ` Jacob Pan
2013-11-21 0:54 ` Jacob Pan
2013-11-21 8:21 ` Peter Zijlstra
2013-11-21 16:07 ` Paul E. McKenney
2013-11-21 16:21 ` Arjan van de Ven
2013-11-21 19:19 ` Paul E. McKenney
2013-11-21 19:45 ` Arjan van de Ven
2013-11-21 20:07 ` Paul E. McKenney
2013-11-22 0:10 ` Jacob Pan
2013-11-22 4:20 ` Paul E. McKenney
2013-11-22 11:33 ` Peter Zijlstra
2013-11-22 17:17 ` Paul E. McKenney
2013-11-21 16:29 ` Peter Zijlstra
2013-11-21 17:27 ` Paul E. McKenney
2013-11-20 16:04 ` [PATCH 4/7] preempt, locking: Rework local_bh_{dis,en}able() Peter Zijlstra
2013-11-20 16:04 ` [PATCH 5/7] locking: Optimize lock_bh functions Peter Zijlstra
2013-11-20 16:04 ` [PATCH 6/7] sched: Clean up preempt_enable_no_resched() abuse Peter Zijlstra
2013-11-20 18:02 ` Eliezer Tamir
2013-11-20 18:15 ` Peter Zijlstra
2013-11-20 20:14 ` Eliezer Tamir
2013-11-21 10:10 ` Peter Zijlstra
2013-11-21 13:26 ` Eliezer Tamir
2013-11-21 13:39 ` Peter Zijlstra
2013-11-22 6:56 ` Eliezer Tamir
2013-11-22 11:30 ` Peter Zijlstra
2013-11-26 7:15 ` Eliezer Tamir
2013-11-26 10:51 ` Thomas Gleixner
2013-11-20 16:04 ` [PATCH 7/7] preempt: Take away preempt_enable_no_resched() from modules Peter Zijlstra
2013-11-20 18:54 ` Jacob Pan
2013-11-20 19:00 ` Peter Zijlstra
2013-11-20 19:18 ` Peter Zijlstra
2013-11-20 19:29 ` Jacob Pan
2013-11-20 16:34 ` [PATCH 0/7] Cure some vaux idle wrackage Peter Zijlstra
2013-11-20 17:19 ` Jacob Pan
2013-11-20 17:24 ` Peter Zijlstra
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=528CF028.2040002@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=bitbucket@online.de \
--cc=christopher.leech@intel.com \
--cc=davem@davemloft.net \
--cc=eliezer.tamir@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rjw@rjwysocki.net \
--cc=rui.zhang@intel.com \
--cc=tglx@linutronix.de \
/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.