[lkml]   [2008]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 00/37] Linux Kernel Markers instrumentation for sched-devel.git
On Mon, 2008-04-28 at 11:36 -0700, Andrew Morton wrote:
> On Sat, 26 Apr 2008 21:38:54 +0200 Peter Zijlstra <> wrote:
> > On Thu, 2008-04-24 at 11:03 -0400, Mathieu Desnoyers wrote:
> > > Hi Ingo,
> > >
> > > Here is a rather large patchset applying kernel instrumentation to
> > > sched-devel.git. It includes, mainly :
> >
> > I saw this land in sched-devel, how about this:
> >
> > ---
> > Subject: sched: de-uglyfy marker impact
> >
> > These trace_mark() things look like someone puked all over the code,
> lol.

Glad to lighten your day a little ;-)

> > lets hide the ugly bits.
> It hides the cosmetically-ugly bits, but not the deeply ugly: each of these
> trace points is an extension to the kernel->userspace API, with all that
> this implies.

Agreed, and I'm rather concerned about that as well. OTOH its very
unlikely we'll ever have a Linux that will not have a context switch, or
task wakeup operation.

So tracing these and things like syscall seem safe enough to do -
although I wish it wouldn't look so ugly.

As for some of these other trace points in this set, dubious.

We can of course clearly state that any marker is free of API
constraints and users will have to cope with them changing. But I'm not
sure that's a realistic position.

> > +static inline
> > +void trace_kernel_sched_wakeup(struct rq *rq, struct task_struct *p)
> When doing this please put the newline immediately preceding the function
> name. Putting it between the `inline' and the return-type-declaration is
> weird.

Sure. Just to clarify my rationale, I like to keep the return type on
the same line when possible so you get a complete picture - the static
and inline qualifiers seem less important, but I don't particularly

 \ /
  Last update: 2008-04-28 21:55    [W:0.111 / U:39.036 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site