public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Daniel Walker <dwalker@fifo99.com>,
	Linus Walleij <linus.ml.walleij@gmail.com>,
	Andrew Victor <linux@maxim.org.za>,
	Haavard Skinnemoen <hskinnemoen@atmel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	John Stultz <johnstul@linux.vnet.ibm.com>,
	linux-arm-kernel@lists.arm.linux.org.uk,
	linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched: sched_clock() clocksource handling.
Date: Tue, 2 Jun 2009 16:35:15 +0900	[thread overview]
Message-ID: <20090602073515.GB17710@linux-sh.org> (raw)
In-Reply-To: <1243927502.23657.5619.camel@twins>

On Tue, Jun 02, 2009 at 09:25:02AM +0200, Peter Zijlstra wrote:
> On Tue, 2009-06-02 at 16:17 +0900, Paul Mundt wrote:
> 
> > @@ -362,6 +364,9 @@ static struct clocksource *select_clocksource(void)
> >  	if (next == curr_clocksource)
> >  		return NULL;
> >  
> > +	if (next->flags & CLOCK_SOURCE_USE_FOR_SCHED_CLOCK)
> > +		sched_clocksource = next;
> > +
> >  	return next;
> >  }
> >  
> > @@ -440,7 +445,21 @@ void clocksource_unregister(struct clocksource *cs)
> >  	list_del(&cs->list);
> >  	if (clocksource_override == cs)
> >  		clocksource_override = NULL;
> > +
> >  	next_clocksource = select_clocksource();
> > +
> > +	/*
> > +	 * If select_clocksource() fails to find another suitable
> > +	 * clocksource for sched_clocksource and we are unregistering
> > +	 * it, switch back to jiffies.
> > +	 */
> > +	if (sched_clocksource == cs) {
> > +		rcu_assign_pointer(sched_clocksource, &clocksource_jiffies);
> > +		spin_unlock_irqrestore(&clocksource_lock, flags);
> > +		synchronize_rcu();
> > +		return;
> > +	}
> > +
> >  	spin_unlock_irqrestore(&clocksource_lock, flags);
> >  }
> 
> 
> What if there's multiple CLOCK_SOURCE_USER_FOR_SCHED_CLOCK [ damn, thats
> a long name to type :-) ] ?
> 
> That is, should we have logic in select_clocksource that does:
> 
>   if ((next->flags & ..) && next->prio > sched_clocksource->prio)
> 
> or whatever, so that it picks the best one?
> 
> Same for unregister, should we re-evaluate all clocksources before
> falling back to basic?

We already do via select_clocksource(), if we are unregistering the
current one then a new one with the flag set is selected. Before that,
the override is likewise given preference, and we fall back on jiffies if
there is nothing else. I suppose we could try and find the "best" one,
but I think the override and manual clocksource selection should be fine
for this.

Now that you mention it though, the sched_clocksource() assignment within
select_clocksource() happens underneath the clocksource_lock, but is not
using rcu_assign_pointer(). If the assignment there needs to use
rcu_assign_pointer() then presumably all of the unlock paths that do
select_clocksource() will have to synchronize_rcu()?

  reply	other threads:[~2009-06-02  7:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02  7:17 [PATCH] sched: sched_clock() clocksource handling Paul Mundt
2009-06-02  7:25 ` Peter Zijlstra
2009-06-02  7:35   ` Paul Mundt [this message]
2009-06-02  7:41     ` Peter Zijlstra
2009-06-02  7:54       ` Paul Mundt
2009-06-02  8:00         ` Peter Zijlstra
2009-06-02  8:00           ` Paul Mundt
2009-06-02 11:49         ` Daniel Walker
2009-06-02 20:21           ` Thomas Gleixner
2009-06-03  3:36           ` Paul Mundt
2009-06-03 14:58             ` Daniel Walker
2009-06-02 12:26         ` Peter Zijlstra
2009-06-02 20:17       ` Thomas Gleixner
2009-06-03  3:39         ` Paul Mundt
2009-06-02 14:17 ` Rabin Vincent
2009-06-02 14:25   ` Peter Zijlstra
2009-06-02 22:24 ` john stultz
2009-06-03  7:03   ` 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=20090602073515.GB17710@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=akpm@linux-foundation.org \
    --cc=dwalker@fifo99.com \
    --cc=hskinnemoen@atmel.com \
    --cc=johnstul@linux.vnet.ibm.com \
    --cc=linus.ml.walleij@gmail.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@maxim.org.za \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --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