Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Subject: [ltt-dev] Updated TODO list before releasing LTTng buffering	to LKML
Date: Tue, 28 Oct 2008 23:19:45 -0400	[thread overview]
Message-ID: <20081029031945.GA1425@Krystal> (raw)
In-Reply-To: <48A9612F918F4C2CAE3A6A6BB05F52A6@zhaoleiwin>

* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> 
> > Hi everyone,
> > 
> > Thanks for the steady work those past weeks. We are close to a
> > releasable result. I have been delighted to see people from Fujitsu
> > helping on various items in the past weeks. Thanks to all those who
> > report issues and/or provide patches.
> > 
> > Here is an updated Todo list before posting LTTng-buffering to LKML
> > 
> > Timestamping :
> > 
> > - Use kernel/time/tsc-sync.c in MIPS to detect unsync TSCs.
> > - Tweak kernel/time/tsc-sync.c so it supports sync detection between two
> >  CPUs so it can be used to replace arch/x86/kernel/tsc_sync.c
> > - I plan to leave the current cache-line bouncing time source for CPUs
> >  which have unsynched TSC, but to printk a warning telling the user to
> >  disabled freq. scaling and halt in idle to make sure the clocks are
> >  synchronized if he expects precise timestamping and good scalability
> >  to large number of nodes. Let's keep room for improvement on this
> >  aspect for later.
> > 
> > 
> > Markers :
> > 
> > - Tie the markers to event IDs and buffer name. That will permit to
> >  simplify a lot of stuff currently in ltt-marker-control.ko. It will
> >  also remove the need for a global event ID assignation, making it
> >  per-buffer (in LTTng terminology : per-channel).
> >  (will be done by myself soon)
> > 
> > - move ltt/ltt-marker-control.c /proc interface to debugfs
> >  I think we should integrate its directory tree to the new LTTng tracer
> >  debugfs API like this :
> > 
> >  /debugfs/ltt/events/buffer_name/marker_name/
> >    where we find files like :
> >    state
> >      write : 1/0 (on/off)
> >      read  : 1/0 (on/off)
> >    format
> >      read : marker format string
> Hello, Mathieu,
> 
> So we need to create a marker's debugfs-directory when user insmod
>  a module with markers.
> But i think we don't have a callback when user insmod, and we
>  should avoid to patch kernel/module.c for this kind of function.
> 
> So, maybe we can only "echo marker_name 0/1" > marker-control.
> Dou you have suggestion for me?
> 


Yes, we do have a callback in insmod.

See :

load_module()

#ifdef CONFIG_MARKERS
        if (!mod->taints)
                marker_update_probe_range(mod->markers,
                        mod->markers + mod->num_markers);
#endif

We would probably also have to get a callback in free_module to remove
the marker directory entry when the last marker reference is gone. The
same

#ifdef CONFIG_MARKERS
        if (!mod->taints)
                marker_update_probe_range(mod->markers,
                        mod->markers + mod->num_markers);
#endif

Could probably be used in free_module.

One of the main difference in the marker.c code will be that we would
have to keep a marker entry (in the hash table) for every marker present
in the kernel core or in modules. It will contain the reference count,
incremented each time a marker struct is encountered in the core kernel
or in loaded modules, and decremented at each time is is encountered at
module unload.

I know this kind of directory structure is a bit more elaborated than
what is currently present in LTTng and also more complex to implement,
but there seemed to be a strong agreement amongst people present at the
tracing meeting at the Linux Plumber Conference that this kind of API is
expected and indeed very simple to understand and use.

Mathieu

> > 
> >  (being done by Fujistsu)
> > 
> > 
> > LTTng tracer :
> > 
> > - Rip apart ltt/ltt-core.c and put it in ltt/ltt-tracer.c. This
> >  "builtin" part of LTTng can now sit in a module without any problem.
> >  This can be done because we have the markers to abstract all
> >  interactions with the tracer.
> >  (will be done by myself soon)
> > 
> > - switch ltt-control.ko (currently over netlink) to debugfs
> >  (being done by Fujistsu)
> > 
> > - Create a ltt-ascii.ko kernel module which merge-sorts the buffers and exports
> >  them to userspace through a debugfs file.
> >  (will be done by Fujistu)
> > 
> > - merge a simplified lttv in lttng
> >  (will be done by myself)
> > 
> > As always, feel free to indicate if you are willing to help on any of
> > these items. If you need some pointers to the current state of work for
> > a particular item, just ask and I'll give you the pointer to the patch
> > within the -lttng git tree.
> > 
> > Thanks,
> > 
> > Mathieu
> > 
> > -- 
> > Mathieu Desnoyers
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> > 
> >
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68




  reply	other threads:[~2008-10-29  3:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 15:21 Mathieu Desnoyers
2008-10-29  2:41 ` Zhaolei
2008-10-29  3:19   ` Mathieu Desnoyers [this message]
2008-10-29  5:35     ` [ltt-dev] Updated TODO list before releasing LTTng bufferingto LKML Zhaolei
2008-10-29  5:41       ` [ltt-dev] Updated TODO list before releasing LTTng bufferingtoLKML Zhaolei
2008-10-29 15:23       ` [ltt-dev] Updated TODO list before releasing LTTng bufferingto LKML Mathieu Desnoyers
2008-10-30  0:51         ` [ltt-dev] Updated TODO list before releasing LTTng bufferingtoLKML Zhaolei
2008-10-30  3:05           ` Mathieu Desnoyers
2008-10-30  3:59             ` [ltt-dev] Updated TODO list before releasing LTTngbufferingtoLKML Zhaolei

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=20081029031945.GA1425@Krystal \
    --to=compudj@krystal.dyndns.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox