lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091126115605.GA15189@elte.hu>
Date:	Thu, 26 Nov 2009 12:56:05 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frédéric Weisbecker 
	<fweisbec@...il.com>
Cc:	Tejun Heo <tj@...nel.org>, Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Mike Galbraith <efault@....de>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 1/4 tip/sched/core] sched: rename preempt_notifier to
 sched_notifier and always enable it


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Thu, 2009-11-26 at 11:32 +0100, Peter Zijlstra wrote:
> > On Thu, 2009-11-26 at 11:29 +0100, Ingo Molnar wrote:
> > > * Tejun Heo <tj@...nel.org> wrote:
> > > 
> > > > Rename preempt_notifier to sched_notifier, move it from preempt.h to 
> > > > sched.h, drop sched_ prefixes from ops names and make sched_notifier 
> > > > always enabled.
> > > > 
> > > > This is to prepare for adding more notification hooks.  This patch 
> > > > doesn't make any functional changes.
> > > 
> > > The sched notifiers and the various event notifiers we have in the same 
> > > codepaths should really be unified into a single callback framework.
> > > 
> > > We have these _5_ callbacks:
> > > 
> > > ....
> > >         perf_event_task_sched_out(prev, next, cpu);
> > > ....
> > >         fire_sched_out_notifiers(prev, next);
> > > ....
> > >         trace_sched_switch(rq, prev, next);
> > > ....
> > >         perf_event_task_sched_in(current, cpu_of(rq));
> > > 	fire_sched_in_notifiers(current);
> > > ....
> > > 
> > > That could be done with just two callbacks - one for sched-out, one for 
> > > sched-in.
> > > 
> > > The best way to do that would be to use two TRACE_EVENT() callbacks, 
> > > make them unconditional and register to them. (with wrappers to make it 
> > > all convenient to use)
> > > 
> > > This requires some work but needs to be done.
> > 
> > Ugh,.. it also makes TRACE_EVENT unconditional.
> > 
> > That really wants a separate option.. What we could do is take regular
> > notifier lists and extend them to auto-generate a tracepoint when the
> > trace stuff is enabled or something.

I wouldnt mind some form of TRACE_EVENT_CALLBACK() thing whose callback 
facility is always available, even if CONFIG_PERF_EVENTS and 
CONFIG_TRACING is disabled.

It might grow out of notifier.h - albeit i suspect the shorter path 
would be to grow it from TRACE_EVENT().

( The various pagefault notifiers in arch/x86/mm/fault.c could use this 
  facility too. )

What we definitely dont want is the proliferation of callbacks.

> Also, there is this thing about direct and indirect function calls.

Yeah. The norm would be for those points to be disabled and have near 
zero overhead. If it has callbacks registered it should be light-weight.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ