mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
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: Wed, 1 Jul 2015 11:08:49 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1507011046420.3916@nanos> (raw)
In-Reply-To: <alpine.DEB.2.11.1506261437280.4037@nanos>

On Fri, 26 Jun 2015, Thomas Gleixner wrote:
> On Fri, 26 Jun 2015, Preeti U Murthy wrote:
> > On 06/26/2015 01:17 PM, Thomas Gleixner wrote:
> > >  	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).
> 
> Hmm. Need to think a bit more about this convoluted maze ...

Actually, that does not matter at all because the CPU which runs the
broadcast does not need to program its own next event.

That's just redundant because the next event on this cpu is already
programmed in the cpu local timer device and the associated hrtimer is
in the tree. The cpu does not go into deep idle so it just works and
we spare the set/clear bit dance along with the hrtimer update.

Now, there is another caveat. If the cpu is not holding the broadcast
device and has the first expiring timer then the broadcast device
might migrate over and we should clear the cpu in the
broadcast_oneshot_mask.

I so wish we had never invented that broadcast crap at all.

Thanks,

	tglx

  parent reply	other threads:[~2015-07-01  9:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-25 10:27 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 [this message]
2015-06-26 12:58           ` Sudeep Holla
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=alpine.DEB.2.11.1507011046420.3916@nanos \
    --to=tglx@linutronix.de \
    --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=sudeep.holla@arm.com \
    /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

all inboxes | Powered by JetHome®