linux-kernel - Re: [PATCH 1/4 tip/sched/core] sched: rename preempt_notifier to sched

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: <4B0F356B.3040206@kernel.org>
Date:	Fri, 27 Nov 2009 11:11:55 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	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

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.

The thing is that I've been sitting on these workqueue patches for
months now and I really want them in stable tree at this point.  So,
how about putting the current simplistic notifier code into a sched/
branch which is not pushed to Linus and then after pushing the
workqueue patches, I'll work on the notifiers branch before pushing
the whole thing to Linus.  Although the scheduler notifier changes
necessary for c-m-workqueue adds more notifiers, it's just extension
of an existing facility and pretty isolated change from other
workqueue changes.

How does that sound?

Thanks.

-- 
tejun
--
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/