public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: mingo@kernel.org, tglx@linutronix.de, rjw@rjwysocki.net,
	nicolas.pitre@linaro.org, preeti@linux.vnet.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions
Date: Mon, 24 Feb 2014 16:16:44 +0100	[thread overview]
Message-ID: <20140224151644.GY27965@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <530B6147.6010301@linaro.org>

On Mon, Feb 24, 2014 at 04:12:07PM +0100, Daniel Lezcano wrote:
> On 02/24/2014 04:00 PM, Peter Zijlstra wrote:
> >
> >
> >None of this actually applies :/ I'm having major conflicts in
> >driveres/cpuidle/cpuidle.c.
> 
> Ok, except if I am missing something, the patchset is based on top of
> tip/sched/core (commit 6990566).

Ah! So the below commit from the timers/core branch is in the way.

Thomas, Ingo, how do we go about solving this sched/core vs timers/core
conflict?

---

# git log 6990566..tip/master drivers/cpuidle/
commit 2f60b8ae0b2a006e4d3452e57ea98b59ce985d14
Merge: 9eaf844efc23 849401b66d30
Author: Ingo Molnar <mingo@kernel.org>
Date:   Sat Feb 22 18:52:27 2014 +0100

    Merge branch 'timers/core'

commit ba8f20c2eb4158a443e9d6a909aee5010efa0c69
Author: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Date:   Fri Feb 7 13:36:52 2014 +0530

    cpuidle: Handle clockevents_notify(BROADCAST_ENTER) failure
    
    Some archs set the CPUIDLE_FLAG_TIMER_STOP flag for idle states in which the
    local timers stop. The cpuidle_idle_call() currently handles such idle states
    by calling into the broadcast framework so as to wakeup CPUs at their next
    wakeup event. With the hrtimer mode of broadcast, the BROADCAST_ENTER call
    into the broadcast frameowork can fail for archs that do not have an external
    clock device to handle wakeups and the CPU in question has thus to be made
    the stand by CPU. This patch handles such cases by failing the call into
    cpuidle so that the arch can take some default action. The arch will certainly
    not enter a similar idle state because a failed cpuidle call will also implicitly
    indicate that the broadcast framework has not registered this CPU to be woken up.
    Hence we are safe if we fail the cpuidle call.
    
    In the process move the functions that trace idle statistics just before and
    after the entry and exit into idle states respectively. In other
    scenarios where the call to cpuidle fails, we end up not tracing idle
    entry and exit since a decision on an idle state could not be taken. Similarly
    when the call to broadcast framework fails, we skip tracing idle statistics
    because we are in no further position to take a decision on an alternative
    idle state to enter into.
    
    Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
    Cc: deepthi@linux.vnet.ibm.com
    Cc: paulmck@linux.vnet.ibm.com
    Cc: fweisbec@gmail.com
    Cc: paulus@samba.org
    Cc: srivatsa.bhat@linux.vnet.ibm.com
    Cc: svaidy@linux.vnet.ibm.com
    Cc: peterz@infradead.org
    Cc: benh@kernel.crashing.org
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: linuxppc-dev@lists.ozlabs.org
    Link: http://lkml.kernel.org/r/20140207080652.17187.66344.stgit@preeti.in.ibm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>


  reply	other threads:[~2014-02-24 15:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-24 13:55 [PATCH V2 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions Daniel Lezcano
2014-02-24 13:55 ` [PATCH V2 2/5] cpuidle/idle: Move the cpuidle_idle_call function to idle.c Daniel Lezcano
2014-02-24 13:55 ` [PATCH V2 3/5] idle: Reorganize the idle loop Daniel Lezcano
2014-02-24 13:55 ` [PATCH V2 4/5] idle: Move idle conditions in cpuidle_idle main function Daniel Lezcano
2014-02-24 14:59   ` Peter Zijlstra
2014-02-24 15:39     ` Daniel Lezcano
2014-02-24 16:05       ` Peter Zijlstra
2014-02-24 17:03         ` Daniel Lezcano
2014-02-24 17:22           ` Peter Zijlstra
2014-02-24 17:54             ` Nicolas Pitre
2014-02-24 17:58               ` Peter Zijlstra
2014-02-24 19:04             ` Daniel Lezcano
2014-02-24 19:25               ` Peter Zijlstra
2014-02-27 13:32             ` [tip:sched/core] sched/idle: Remove stale old file tip-bot for Peter Zijlstra
2014-02-24 13:55 ` [PATCH V2 5/5] idle: Add more comments to the code Daniel Lezcano
2014-02-24 15:00 ` [PATCH V2 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions Peter Zijlstra
2014-02-24 15:12   ` Daniel Lezcano
2014-02-24 15:16     ` Peter Zijlstra [this message]
2014-02-25  3:35       ` Preeti U Murthy
2014-02-25  3:47 ` Preeti U Murthy
2014-02-25  6:35   ` Daniel Lezcano

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=20140224151644.GY27965@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rjw@rjwysocki.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox