All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Tejun Heo <tj@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Fr??d??ric Weisbecker <fweisbec@gmail.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Mike Galbraith <efault@gmx.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 1/4 tip/sched/core] sched: rename preempt_notifier to sched_notifier and always enable it
Date: Fri, 27 Nov 2009 05:52:09 +0100	[thread overview]
Message-ID: <20091127045209.GA13914@elte.hu> (raw)
In-Reply-To: <4B0F356B.3040206@kernel.org>


* Tejun Heo <tj@kernel.org> wrote:

> Hello, Peter, Ingo.
> 
> 11/26/2009 09:40 PM, Peter Zijlstra wrote:
> > CALLBACK_EVENT() would be my preferred name, and shouldn't live anywhere
> > near the regular tracing bits, the tracing bits could simply add another
> > callback in it when enabled.
> 
> I haven't looked at the mm code but if the scheduler callback 
> requirement isn't gonna explode big time soon and we know which 
> functions are the candidate callbacks at build time, I think this can 
> be done pretty efficiently with an ulong enable mask per task and 
> fixed function dispatch such that no callback case just goes through 
> one likely() conditional test at the tracing point and callback cases 
> are dispatched using conditional direct jump.

Yes - and that's what the tracepoints infrastructure is about.

Btw., longer term it will be faster than a mask check and a 
default-untaken conditional: there's ongoign work to offer runtime 
instruction patching features for tracing callbacks. There's the jump 
patching optimization and also the immediate values patching 
optimization.

We've got old-style notifiers for regular callbacks, we've got new-style 
tracepoints which are callbacks and event source descriptors - and what 
i'm asking for is to have _one_ callback mechanism, and to use that in 
the scheduler. 5 callbacks using 3 different facilities is excessive - 
i'd like to see just two callbacks using one facility.

	Ingo

  reply	other threads:[~2009-11-27  4:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-26  8:00 linux-next: manual merge of the workqueues tree with the tip tree Stephen Rothwell
2009-11-26  8:12 ` Ingo Molnar
2009-11-26  9:15   ` Tejun Heo
2009-11-26  9:26     ` Ingo Molnar
2009-11-26  9:48       ` Tejun Heo
2009-11-26  9:51         ` Ingo Molnar
2009-11-26 10:11           ` [PATCH 1/4 tip/sched/core] sched: rename preempt_notifier to sched_notifier and always enable it Tejun Heo
2009-11-26 10:29             ` Ingo Molnar
2009-11-26 10:32               ` Peter Zijlstra
2009-11-26 11:23                 ` Peter Zijlstra
2009-11-26 11:56                   ` Ingo Molnar
2009-11-26 12:40                     ` Peter Zijlstra
2009-11-27  2:11                       ` Tejun Heo
2009-11-27  4:52                         ` Ingo Molnar [this message]
2009-11-27  5:38                           ` Tejun Heo
2009-11-27  5:46                             ` Ingo Molnar
2009-11-27  6:01                               ` Tejun Heo
2009-11-27  6:13                                 ` Ingo Molnar
2009-11-27  6:16                                   ` Tejun Heo
2009-11-27  6:21                                     ` Ingo Molnar
2009-11-27  6:38                                       ` Tejun Heo
2009-11-27  7:02                                         ` Ingo Molnar
2009-11-26 10:44               ` Tejun Heo
2009-11-27  3:33               ` Paul Mackerras
2009-11-27  4:54                 ` Ingo Molnar
2009-11-26 10:13           ` [PATCH 2/4 tip/sched/core] sched: update sched_notifier and add wakeup/sleep notifications Tejun Heo
2009-11-26 10:13           ` [PATCH 3/4 tip/sched/core] sched: refactor try_to_wake_up() and implement try_to_wake_up_local() Tejun Heo
2009-11-26 10:14           ` [PATCH 4/4 tip/sched/core] sched: implement force_cpus_allowed() Tejun Heo

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=20091127045209.GA13914@elte.hu \
    --to=mingo@elte.hu \
    --cc=efault@gmx.de \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    /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.