All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Paul Mundt <lethal@linux-sh.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, 02 Jun 2009 07:25:02 +0000	[thread overview]
Message-ID: <1243927502.23657.5619.camel@twins> (raw)
In-Reply-To: <20090602071718.GA17710@linux-sh.org>

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?

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Paul Mundt <lethal@linux-sh.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, 02 Jun 2009 09:25:02 +0200	[thread overview]
Message-ID: <1243927502.23657.5619.camel@twins> (raw)
In-Reply-To: <20090602071718.GA17710@linux-sh.org>

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?

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

Thread overview: 36+ 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:17 ` Paul Mundt
2009-06-02  7:25 ` Peter Zijlstra [this message]
2009-06-02  7:25   ` Peter Zijlstra
2009-06-02  7:35   ` Paul Mundt
2009-06-02  7:35     ` Paul Mundt
2009-06-02  7:41     ` Peter Zijlstra
2009-06-02  7:41       ` Peter Zijlstra
2009-06-02  7:54       ` Paul Mundt
2009-06-02  7:54         ` Paul Mundt
2009-06-02  8:00         ` Peter Zijlstra
2009-06-02  8:00           ` Peter Zijlstra
2009-06-02  8:00           ` Paul Mundt
2009-06-02  8:00             ` Paul Mundt
2009-06-02 11:49         ` Daniel Walker
2009-06-02 11:49           ` Daniel Walker
2009-06-02 20:21           ` Thomas Gleixner
2009-06-02 20:21             ` Thomas Gleixner
2009-06-03  3:36           ` Paul Mundt
2009-06-03  3:36             ` Paul Mundt
2009-06-03 14:58             ` Daniel Walker
2009-06-03 14:58               ` Daniel Walker
2009-06-02 12:26         ` Peter Zijlstra
2009-06-02 12:26           ` Peter Zijlstra
2009-06-02 20:17       ` Thomas Gleixner
2009-06-02 20:17         ` Thomas Gleixner
2009-06-03  3:39         ` Paul Mundt
2009-06-03  3:39           ` Paul Mundt
2009-06-02 14:17 ` Rabin Vincent
2009-06-02 14:29   ` Rabin Vincent
2009-06-02 14:25   ` Peter Zijlstra
2009-06-02 14:25     ` Peter Zijlstra
2009-06-02 22:24 ` john stultz
2009-06-02 22:24   ` john stultz
2009-06-03  7:03   ` Peter Zijlstra
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=1243927502.23657.5619.camel@twins \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=dwalker@fifo99.com \
    --cc=hskinnemoen@atmel.com \
    --cc=johnstul@linux.vnet.ibm.com \
    --cc=lethal@linux-sh.org \
    --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=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.