All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Suzuki Poulose <Suzuki.Poulose@arm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH] clockevents: return error from tick_broadcast_oneshot_control if !GENERIC_CLOCKEVENTS_BROADCAST
Date: Fri, 26 Jun 2015 13:58:19 +0100	[thread overview]
Message-ID: <558D4C6B.4090702@arm.com> (raw)
In-Reply-To: <558D46C5.8080307@linux.vnet.ibm.com>



On 26/06/15 13:34, Preeti U Murthy wrote:
> On 06/26/2015 01:17 PM, Thomas Gleixner wrote:
>> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
>> index d39f32cdd1b5..281ce29d295e 100644
>> --- a/kernel/time/tick-broadcast.c
>> +++ b/kernel/time/tick-broadcast.c
>> @@ -662,46 +662,39 @@ static void broadcast_shutdown_local(struct clock_event_device *bc,
>>   	clockevents_switch_state(dev, CLOCK_EVT_STATE_SHUTDOWN);
>>   }
>>
>> -/**
>> - * tick_broadcast_oneshot_control - Enter/exit broadcast oneshot mode
>> - * @state:	The target state (enter/exit)
>> - *
>> - * The system enters/leaves a state, where affected devices might stop
>> - * Returns 0 on success, -EBUSY if the cpu is used to broadcast wakeups.
>> - *
>> - * Called with interrupts disabled, so clockevents_lock is not
>> - * required here because the local clock event device cannot go away
>> - * under us.
>> - */
>> -int tick_broadcast_oneshot_control(enum tick_broadcast_state state)
>> +int __tick_broadcast_oneshot_control(enum tick_broadcast_state state)
>>   {
>>   	struct clock_event_device *bc, *dev;
>> -	struct tick_device *td;
>>   	int cpu, ret = 0;
>>   	ktime_t now;
>>
>> -	/*
>> -	 * Periodic mode does not care about the enter/exit of power
>> -	 * states
>> -	 */
>> -	if (tick_broadcast_device.mode == TICKDEV_MODE_PERIODIC)
>> -		return 0;
>> +	if (!tick_broadcast_device.evtdev)
>> +		return -EBUSY;
>>
>> -	/*
>> -	 * We are called with preemtion disabled from the depth of the
>> -	 * idle code, so we can't be moved away.
>> -	 */
>> -	td = this_cpu_ptr(&tick_cpu_device);
>> -	dev = td->evtdev;
>> -
>> -	if (!(dev->features & CLOCK_EVT_FEAT_C3STOP))
>> -		return 0;
>> +	dev = this_cpu_ptr(&tick_cpu_device)->evtdev;
>>
>>   	raw_spin_lock(&tick_broadcast_lock);
>>   	bc = tick_broadcast_device.evtdev;
>>   	cpu = smp_processor_id();
>>
>>   	if (state == TICK_BROADCAST_ENTER) {
>> +		/*
>> +		 * If the current CPU owns the hrtimer broadcast
>> +		 * mechanism, it cannot go deep idle and we do not add
>> +		 * the CPU to the broadcast mask. We don't have to go
>> +		 * through the EXIT path as the local timer is not
>> +		 * shutdown.
>> +		 */
>> +		ret = broadcast_needs_cpu(bc, cpu);
>> +
>> +		/*
>> +		 * If the hrtimer broadcast check tells us that the
>> +		 * cpu cannot go deep idle, or if the broadcast device
>> +		 * is in periodic mode, we just return.
>> +		 */
>> +		if (ret || tick_broadcast_device.mode == TICKDEV_MODE_PERIODIC)
>> +			goto out;
>
> The check on PERIODIC mode is good, but I don't see the point of moving
> broadcast_needs_cpu() up above. broadcast_shutdown_local() calls
> broadcast_needs_cpu() internally.
>
> Besides, by jumping to 'out', we will miss programming the broadcast
> hrtimer in tick_broadcast_set_event() below, if the cpu happen to be the
> broadcast cpu(which is why it was not allowed to go to deep idle).
>

I tested the updated patch and found issues. I am seeing some random
behaviour(with GENERIC_CLOCKEVENTS_BROADCAST=y TICK_ONESHOT=y):
1. sometimes all the CPUs have entered deeper idle states(though very
    rare, finding it difficult to hit this scenario)
2. few other times I see one CPU in shallow state which matches the
    above explanation of missing hrtimer programming.

Regards,
Sudeep

  parent reply	other threads:[~2015-06-26 12:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-25 10:27 [PATCH] clockevents: return error from tick_broadcast_oneshot_control if !GENERIC_CLOCKEVENTS_BROADCAST Sudeep Holla
2015-06-25 13:55 ` Thomas Gleixner
2015-06-25 15:30   ` Sudeep Holla
2015-06-26  5:08     ` Preeti U Murthy
2015-06-26  7:47       ` Thomas Gleixner
2015-06-26 11:25         ` Preeti U Murthy
2015-06-26 11:50           ` Thomas Gleixner
2015-06-26 12:37             ` Preeti U Murthy
2015-06-26 12:34         ` Preeti U Murthy
2015-06-26 12:38           ` Thomas Gleixner
2015-06-26 12:46             ` Preeti U Murthy
2015-07-01  9:08             ` Thomas Gleixner
2015-06-26 12:58           ` Sudeep Holla [this message]
2015-06-26  8:38       ` Sudeep Holla
2015-06-26  4:59   ` Preeti U Murthy

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=558D4C6B.4090702@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Suzuki.Poulose@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rafael.j.wysocki@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.