Re: patches to actually use markers?

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Frank Ch. Eigler (fche@redhat.com) wrote:
> Hi -
> 
> On Fri, Nov 16, 2007 at 05:03:14PM -0500, Mathieu Desnoyers wrote:
> > [...]
> > We currently have three distinct events for a system call :
> > 
> > syscall entry, with syscall id and instruction pointer
> > the syscall specific instrumentation (opt)
> > syscall exit
> 
> > [...]  Instrumentation within the syscall specific function helps
> > knowing when/if the operation has really been done _within the
> > kernel_. [...]
> 
> Not just that - but *what* the actual operation was.
> 

One could argue that by saving the syscall parameters, we could probably
remove some internal kernel instrumentation because it would duplicate
the information.

> > [...] Given these two opposite sets of constraints, I think having
> > more than one instrumentation site per syscall makes sense.
> 
> Sure - what bothers me is the satisfaction with the inconsistency of
> some system calls having no specific markers.
> 

I don't see much difference between the two approaches : if you create
a syscall audit-like probe module, you will have to deal with each
architecture and describe each system externally. Therefore, there is a
per system call / per architecture action required from the developers.
On the other hand, if we instrument the functions called by these system
calls, which are often in architecture independent code, we only have to
add instrumentation for each system call, (removing the "per
architecture" multiplicator).

We also come back to the distinction between maintaining a list of
system calls outside the actual kernel code base, making it harder to
follow the code flow, vs adding the instrumentation directly in the
kernel code.

Even if the probes are packaged with the kernel, adding a new system
call will require to go change yet another list that would keep track of
the system calls for each architecture.

> > Moreover, markers are really cheap... :)
> 
> I'm not the one who must buy what we're selling - it's the kernel
> maintainers. :-)
> 
> > [...]  Yes, refcount would be the way to go. The code is currently
> > in kernel/sched.c, since it touches the threads. I would have to add
> > the refcount. It will be in the next LTTng prerelease.
> 
> But you see, if markers are not just really cheap but really really
> cheap, then you don't need the task flag, nor the new API for
> refcounting the flags' clients, nor the new machinery to propagate the
> flag to new tasks.  You just put unconditional markers in there and
> let the possible multiple marker handlers do their own filtering.
> 

In per-architecture _assembly_ code ??

Note that the markers are C macros. We put them in syscall_trace, which
is a C callback made exactly for this kind of purpose. However, there is
a performance penality involved in setting up the stack and calling this
function, so we have to control wether or not it should be called. We
are not even talking about marker code there.

Mathieu

> 
> - FChE

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68