+++ /dev/null
-<?xml version="1.0" encoding="UTF-8" ?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
- "/usr/share/sgml/docbook/dtd/4.3/xdocbook.dtd">
-<!--<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" >-->
-
-<book>
-
-<bookinfo>
-<title>Spécifications du filtre de Linux Trace Toolkit Viewer</title>
-<authorgroup>
-<author>
-<firstname>Mathieu</firstname>
-<surname>Desnoyers</surname>
-</author>
-</authorgroup>
-
-<date>26/01/2005</date>
-<releaseinfo>1.00.00</releaseinfo>
-
-<abstract>
-<para>
-Ce document décrit les spécifications requises pour la fonctionnalité de
-filtrage pour l'application
-<application>Linux Trace Toolkit Viewer</application>.
-
-</para>
-</abstract>
-
-<keywordset>
-<keyword>Linux Trace Toolkit Viewer</keyword>
-<keyword>spécification</keyword>
-<keyword>filtre</keyword>
-<keyword>specification</keyword>
-<keyword>filter</keyword>
-</keywordset>
-
-</bookinfo>
-<chapter>
-<title>Introduction</title>
-
-<para>
-Le filtre de Linux Trace Toolkit Viewer est une fonctionnalité nécessaire pour
-rendre l'outil pleinement utilisable. Des cas typiques de filtrage ont déjà été
-identifiés : filtrer par CPU ou par ID d'événement.
-</para>
-<para>
-Cependant, un utilisateur plus avancé peut vouloir filtrer selon n'importe quel
-champs d'information disponible lors de la lecture d'un événement. L'approche
-qui sera suivie, afin d'assurer l'applicabilité du filtrage aux différents types
-de traces, sera de ne pas limiter les champs selon lesquels le filtrage pourra
-être fait.
-</para>
-<para>
-Comme le filtrage se fait à la lecture de chaque événement, il peut rapidement
-devenir un goulot d'étranglement important. Les performances doivent donc être
-un souci de taille lors de la réalisation de cette fonctionnalité. C'est
-pourquoi l'architecture proposée se base sur une compilation des règles de
-filtrage lors de leur définition afin de générer une structure de données
-optimale pour le parcours de la trace.
-</para>
-<para>
-Ce document explique les différents défis à surmonter dans les différents
-sous-modules du filtre, soit : la partie "core" du filtre, qui sera intégrée,
-comme son nom l'indique, au coeur de l'application ainsi que les parties
-modulaires textes et graphiques. À la fin du document, des optimisations
-éventuelles sont énoncées, sans plus. Elles pourront être utiles dans le cas où
-les performances s'avéreraient problématiques.
-</para>
-<para>
-Ce document est le fruit d'un échange entre Michel Dagenais et moi-même, Mathieu
-Desnoyers. Certains passages sont laissés sous leur forme originale.
-</para>
-
-</chapter>
-
-
-<chapter>
-<title>Design</title>
-
-<sect1>
-<title>Core</title>
-
-<para>
- Application des règles de filtrage aux événements. Les règles de
- filtrage pourraient être représentées par un arbre. Cette section du
- filtrage est assez intégrée au reste de l'application pour mériter d'être
- au coeur même de lttv (pas dans un module séparé). Les feuilles de l'arbre
- sont des 3-tuples (champs, relation, valeur), alors que les noeuds
- intermédiaires sont des relations logiques (and, or, xor, not). Le and, le
- or et le xor sont limités à deux enfants, alors que le not est limité à un
- seul enfant.
-</para>
-<para>
- Les champs du 3-tuple devraient respecter une arborescence qui représente
- l'organisation des données dans les événements. Celles-ci sont, lors de la
- lecture de la trace, accessibles via les structures :
-</para>
-<itemizedlist>
-<listitem><para>LttEvent (plus les champs spécifiques à l'événement)</para></listitem>
-<listitem><para>LttvTracefile</para></listitem>
-<listitem><para>LttvTrace</para></listitem>
-<listitem><para>LttvTraceset</para></listitem>
-<listitem><para>LttvState</para></listitem>
-</itemizedlist>
-<para>
- On pourrait donc, au niveau de la description du champs, représenter
- celui-ci par une chaîne de caractères imbriquable dont les niveaux sont
- séparés par le ".". Voici la représentation des niveaux d'imbrication :
-</para>
-<para>
-<literallayout class="monospaced">
- *
- |->event (pour accéder aux champs sous LttEvent)
- | |->name (string)
- | |->category (string)
- | |->time (LttTime)
- | |->tsc (LttCycleCount)
- | |->fields
- | |->"event name"
- | |->"field name"
- | |->"sub-field name"
- | |->...
- | |->"leaf-field name" (field type)
- |
- |->tracefile
- | |->name (string)
- |->trace
- | |->name (string)
- |->state
- |->pid (guint)
- |->ppid (guint)
- |->creation_time (LttTime)
- |->insertion_time (LttTime)
- |->process_name (string)
- |->execution_mode (user_mode, syscall, trap, irq, unknown)
- |->execution_submode (none, unknown)
- |->process_status (wait_fork,wait_cpu,exit,zombie,wait,run,unnamed)
- |->cpu (guint)
-</literallayout>
-</para>
-
-<para>
-L'objet contenant l'arbre des règles de filtrage ainsi que la cache du filtre,
- qu'on pourrait appeler "LttvFilter", serait associé à une trace, non pas à un
- trace set, pour des raisons de performance. En effet, le même nom d'événement
- peut très bien être associé à un ID différent d'une trace à l'autre. Comme on
- ne souhaite pas faire la translation nom->id (qui est coûteuse) à chaque
- utilisation du filtre, on le ferait lors de sa construction. Ceci implique de
- garder un objet LttvFilter par trace. Rien n'empêche cependant d'avoir une
- façon de créer, au niveau usager, des filtres pour toutes les traces d'un
- traceset, mais ceux-ci seront associés à chaque trace du trace set.
-</para>
-
-<para>
-Michel Dagenais :
-</para>
-<para>
-Je m`inquiète beaucoup pour la performance. Il faut pouvoir précompiler
-ces expressions en offset (ltt_field) et avoir un espèce d`index pour ne
-pas passer séquentiellement à travers toutes les règles et pour chaque
-règle interpréter les noms de champs à chaque événement traité!!
-</para>
-
-<para>
-Mathieu Desnoyers :
-</para>
-<para>
-C'est ce que j'avais en tête : fixer les positions des champs au moment de la
-création de la règle de filtrage, quitte à la recalculer si jamais la trace
-change en cours de route (mais ça ne devrait pas arriver, puisque les paires
-(facility, event id) sont uniques au cours d'une trace).
-</para>
-
-<para>
-Cependant, de la manière dont je vois ça, on aura pas le choix de se garder un
-arbre représentant l'expression logique et de le parcourir séquentiellement pour
-chaque événement. On peut évidemment éviter de balayer certaines branches en se
-basant sur les relations and, or, xor lors du parcours.
-</para>
-
-<para>
-Donc, je vois ça, dans le pire cas, comme un parcours infixe de l'arbre
-représentant les règles. Chaque feuille serait une règle représentée par un
-3-tuple (position, (type, relation), valeur), où chaque paire de (type,relation)
-devrait être défini pour chaque type (possiblement incorrect, comme la relation
-< sur un type string). Lors de la compilation, on passerait du 3-tuple (champs,
-relation, valeur) à un 3-tuple (position, (type, relation), valeur).
-</para>
-
-<para>
-À noter : un simple offset n'est en réalité pas assez pour représenter la
-position, puisque toutes les données ne résident pas dans une seule structure.
-Certaines sont dans le contexte (TracesetContext), d'autres dans la structure de
-l'événement. Il faut donc décrire la position, en réalité, comme une paire
-(structure, offset), où nous limitons structure aux noms de structure connus
-(qui peuvent être encodés sur la forme de GQuarks) : {LTTV_TRACE,
-LTTV_TRACEFILE, LTTV_TRACE_STATE, LTT_EVENT}.
-</para>
-
-<para>
-Lors de la compilation, on a, en entrée, le tuple :
-</para>
-
-<para>
-(champs, relation, valeur)
-</para>
-
-<para>
-où champs est un tuple : (structure, offset, type)
-</para>
-
-<para>
-On produit, en sortie, (toujours dans la même structure en arbre pour les
-expressions logiques), les 3-tuples suivants (aux feuilles) :
-</para>
-
-<para>
-(position, fonction, valeur)
-</para>
-
-<para>
-où :
-<simplelist type="inline">
-<member>position = (structure, offset)</member>
-<member>fonction = (type, relation)</member>
-</simplelist>
-</para>
-
-<para>
-Il me reste une question : que fait-on lors qu'un facility est rechargé en cours
-de traçage ? Les événements vont-ils changer d'id ?
-</para>
-
-<para>
-Michel Dagenais :
-</para>
-<para>
-Non, c`est un nouveau facility avec le même nom mais un fingerprint
-différent qui s`ajoute puisqu`il est possible que des modules utilisent
-l`ancienne version alors que d`autres utilisent la nouvelle
-simultanément. Il est possible que les règles ne spécifient que le nom
-de la facilité auquel cas elles pourraient s`appliquer à toutes les
-facilités du même nom et demanderaient d`avoir une précompilation
-différente pour chaque facilité.
-</para>
-
-<para>
-Mathieu Desnoyers :
-</para>
-<para>
-J'en conclue que le 2-tuple (facility, event id) est unique pour la trace, c'est
-ça ?
-</para>
-<para>
-Michel Dagenais :
-</para>
-<para>
-> Oui.
-</para>
-
-</sect1>
-
-<sect1>
-<title>Module texte</title>
-
-<para>
-Lecture d'une chaîne de caractères formée d'expressions
-booléennes qui décrivent le filtre à partir des opérations de base :
-and, or, xor, not
-et de parenthèses : ( et ).
-Les entrées logiques de ce filtre sont composées 3-tuples
-(champs, relation, valeur),
-où le champs est le type d'information (i.e. pid)
-la relation est la limite sur la valeur (i.e. <)
-la valeur est la valeur qui doit être respectée par le champs selon la
-relation. Doit être du type associé au champs. À priori, on utilise
-le type de champs pour savoir sous quel type encoder l'information
-lue, tout en vérifiant le contenu de la chaîne lue pour des
-débordements (overflow) avant encodage vers le type associé.
-La lecture de cette expression booléenne formerait un arbre de règles de
-filtrage, qui serait ensuite utilisé par la partie "core" de filtrage de
-lttv pour être appliqué aux événements lors de la lecture de trace.
-</para>
-
-</sect1>
-
-<sect1>
-<title>Module graphique</title>
-
-<para>
-Une classe filtre graphique serait associée à un arbre
-de règles de filtrage. On pourrait le modifier les objets de la classe
-filtre graphique en invoquant une fenêtre de modification de filtre qui
-permettrait d'entrer les spécifications du filtre à l'aide de champs
-graphiques de sélection (drop down list) pour les types d'éléments selon
-lesquels filtrer, et d'un champs d'entrée de texte libre pour spécifier la
-valeur que ce champs doit prendre. La relation qui doit être appliquée
-(<, >, <=, >=, =) doit être sélectionnée dans un autre drop-down list.
-En plus de la sélection graphique, l'entrée d'une chaîne de caractère serait
-possible pour spécifier le filtre selon l'entrée décrite ci-haut pour le
-module texte.
-</para>
-
-<para>
-Michel Dagenais :
-</para>
-<para>
-Oui, à la rigueur la partie graphique n`est probablement pas tellement
-plus difficile que celle textuelle. On pourrait commencer avec seulement
-la partie graphique qui produit directement la représentation en arbre.
-</para>
-
-<para>
-Mathieu Desnoyers :
-</para>
-<para>
-Comme je prévois réutiliser l'entrée texte à l'intérieur de la fenêtre
-graphique, je crois qu'il est préférable de commencer par l'entrée texte.
-D'ailleurs, l'avantage pour quelqu'un qui commence à contribuer au projet est de
-ne pas avoir à apprendre l'API de GTK en même temps qu'il fait le développement
-de son module. Il est un peu trop facile de ne pas assez découpler la logique
-interne de la présentation.
-</para>
-
-<para>
-Michel Dagenais :
-</para>
-<para>
-Le cas classique est de choisir un CPU ou un type d`événement, auquel
-cas un menu simple de CPU et type serait beaucoup plus pratique que
-d`avoir à taper une expression.
-</para>
-<para>
-Mathieu Desnoyers :
-</para>
-<para>
-On pourrait penser à faire un module graphique de création de filtre de base,
-pour les fonctionnalités les plus utilisées. Celui-ci pourra être étendu par
-la suite, si besoin est. L'intérêt est d'avoir quand-même la possibilité, pour
-un utilisateur plus avancé, de spécifier toutes les caractéristiques via
-l'interface. Dans ce cas, quelqu'un serait tout-à-fait prêt à faire une
-expression pour décrire en détail son filtre. C'est quand-même quelque chose de
-plus en plus commun avec la venue des moteurs de recherche.
-</para>
-
-</sect1>
-
-<sect1>
-<title>Choix de syntaxe, documentation et messages d'erreur</title>
-<para>
-Michel Dagenais :
-</para>
-<para>
-Oui, une partie non négligeable est un choix de syntaxe convivial, la
-documentation et les messages d`erreur...
-</para>
-<para>
-Mathieu Desnoyers :
-</para>
-<para>
-C'est bel et bien ce qui sera perçu par l'utilisateur, de là l'importance..
-</para>
-<para>
-Je me demande s'il est mieux d'adopter une syntaxe un peu à la Google ou bien à
-la C :
-</para>
-
-<para>
-(, ), and, or, xor, not, field op value
-où op peut prendre : <, >, <=, >=, =
-</para>
-
-<para>
-ou bien à la C
-(, ), &, |, ^, !, field op value
-</para>
-
-
-<para>
-Ou bien on peut faire un alphabet mixte entre les deux, où les mots and et &
-seraient équivalents. Ce serait probablement plus facile de reconnaître les
-symboles comme & par contre, et moins limitant sur le traitement du mot
-identifiant le field.
-</para>
-
-<para>
-Mais cette question est de moindre importance : tant qu'on se fixe un standard
-et qu'on le documente, je crois qu'il n'y a pas vraiment de mauvais choix.
-</para>
-
-<para>
-Pour la documentation, l'ajout d'une section au guide de l'utilisateur (déjà en
-docbook) me semble très adéquat.
-</para>
-
-<para>
-Pour les messages d'erreur, il faudra entres autres penser à valider les
-opération par rapport à celles permises pour chaque type. Par exemple, un > n'a
-pas vraiment de sens pour un string.
-</para>
-
-
-<para>
-Michel Dagenais :
-</para>
-<para>
-Je tendrais à prendre la syntaxe C.
-</para>
-
-<para>
-Mathieu Desnoyers :
-</para>
-<para>
-Si on utilise de manière stricte la syntaxe C, il faudrait utiliser ceci :
-</para>
-
-<para>
-&&, ||, ==, (rien pour le xor logique ?)
-</para>
-
-<para>
-Je me dis que, puisque nous n'avons pas besoin des opérations "bitwise", nous
-pourrions utiliser celles-ci.
-</para>
-
-<para>
-Donc, ce que je propose, est d'utiliser l'alphabet utilisé pour les opérateurs
-bitwise du C en tant qu'opérateurs logiques pour notre parser d'expressions de
-filtre :
-</para>
-
-<para>
-&, |, =, ^
-</para>
-
-<para>
-Ceci est un détail sémantique, mais je veux juste m'assurer qu'on est d'accord.
-</para>
-
-
-</sect1>
-
-<sect1>
-<title>Optimisation éventuelles</title>
-
-
-<para>
- "Cache" de filtre, afin d'optimiser le cas courant.
- Au niveau de la partie "core" du filtrage, on pourrait faire une hash
- table indexée par une clé formée d'un xor des champs à filtrer. Alors, si un
- événement possède les même caractéristiques de filtrage, on pourrait accéder à
- la solution (V/F) en O(1). Le coût est de calculer la clé de hashage pour
- chaque événement. L'avantage apparaît lorsqu'il y a plusieurs critères de
- filtrage à comparer. La remise à zéro de cette cache devrait être faite
- lorsqu'il y a des modifications au filtre.
-</para>
-
-<para>
-Michel Dagenais :
-</para>
-<para>
-Les travaux sur l`optimisation de requêtes dans les bases de données est
-probablement pertinent pour ce genre de choses.
-</para>
-
-<para>
-Mathieu Desnoyers :
-</para>
-<para>
-Il faudra que je m'y arrête. Cependant, ceci constitue une optimisation et n'est
-donc pas crucial pour le fonctionnement.
-</para>
-
-
-<para>
-Michel Dagenais :
-</para>
-<para>
-Sauf si c`est inutilisable sans une telle optimisation :-).
-</para>
-
-<para>
-Mathieu Desnoyers :
-</para>
-<para>
-N'est-ce pas toi qui m'a déjà dit, citant Donald Knuth : "Premature
-optimisation is the root of all evil" ? :)
-</para>
-
-<para>
-Effectivement, si on s'aperçoit que c'est trop lent, il faudra passer à cette
-étape.
-</para>
-
-
-</sect1>
-
-</chapter>
-
-
-
-</book>
+++ /dev/null
-GUI Layout
-
-
-
-
-In order to implement the GUI, choices has to be made based on habitual interfaces that we know users are familiar with. The inspiration for these choices came mainly from the Mozilla browser project and also from Openoffice, which are currently used as two userfriendly applications in various Linux distribution at the time of this writing.
-
-This document describes the layout of the GUI in three sections : containers, menus and toolbars.
-
-A status bar is also placed at the bottom of the window.
-
-- Containers
-
-elements hierarchy
-
-Window Mainwindow
-|->vbox
- |->menus
- |->toolbar of the main window
- |->toolbar of the currently selected viewer
- |->notebook
- | |->vpaned
- | |->viewer's widget
- | |->vpaned
- | |->viewer's widget
- | |->vpaned
- | |->...
- |->Status bar
-
-- Menus
-
-Here is a short description of each menu entry
-* by itself means a separator
-
-
-- File
-*New -> *Empty trace set : open a new window with an empty trace set.
- *Clone trace set : copy the content of the current window in a new
- window.
- *
- *Tab : Opens a new tab.
-*Open : open a trace set. Calls a file selection dialog.
-*Close : close the current window.
-*Close Tab : close the current tab.
-*
-*Add trace : Add a trace to the window's traceset. Calls file selection dialog.
-*Remove trace : Removes a trace from the traceset.
-*Save : save the trace set. Calls a file save dialog of no current filename.
-*Save as : save a trace set. Calls a file save dialog.
-*
-*Quit : quit the program.
-
-- Edit ? (not needed for now)
-
-- View
-*Zoom In : Multiply the zoom factor by a certain quantity.
-*Zoom Out : Divide the zoom factor by a certain quantity.
-*Zoom Extended : Show the entire traceset's largest time interval.
-*Go to time : Keep same zoom, ask user for time to center view on and make
- it the current time.
-*Show time frame : ask user for time interval to show.
- (modify zoom and current event in consequence)
-
-- Tools (this is an example of how viewer's menu entries should look like)
-*Move viewer up -> Moves the current viewer up one position.
-*Move viewer down -> Moves the current viewer down one position.
-*Remove : remove the current viewer
-*
-*DumpToFile -> *Dump Text (This is a text module which adds graphical menu
- entries)
- *Dump binary
-* (separator between text tools and graphical tools implies different function
- to register each type of menu entries)
-*Insert Events View : insert this type of viewer
-*Insert ControlFlow View
-- Plugins
-*Load module : ask the user a module to load (list modules in search path).
-*Unload module : list all modules, click to choose, then unload button.
-*Add module search path : ask user for a new path (file selection dialog).
-
-- Options
-//FIXME *Color : change the color of the currently selected element ?
-*Filter : Show traceset's filter option window.
-*Save configuration : Save the currently loaded modules/traceset/filters
- to gconf.
-
-
-(aligned to the right)
-- Help
-*Content
-*About
-
-
-- Toolbar
-
-The toolbar is separated in two parts : like the two lines used in Openoffice. The first one is applying to the top level window (or current tab) while the one below contains the current viewer's toolbar.
-
-So we have something like this :
-
---------------------------------------------------------------------------------
-| Menus |
---------------------------------------------------------------------------------
-| Toolbar of the top level window |
---------------------------------------------------------------------------------
-| Toolbar of the current viewer |
---------------------------------------------------------------------------------
-||Current Tab| |
-|-----------------------------------------------------------------------------||
-||viewers in vpaned ||
-|| ||
-||----------------------------------------------------------------------------||
---------------------------------------------------------------------------------
-| Status bar |
---------------------------------------------------------------------------------
-
-
-The toolbar of the top level window is the only one described in this document, as the second one is defined by the viewers and specific to each of them.
-
-This toolbar is mainly a selection of the menu entries.
-
-New : New window with empty trace set.
-Open : open a trace set.
-Add Trace
-Remove Trace
-Save : save the current trace set.
-Save as
-*
-Zoom in
-(Show the current zoom factor, modifiable)
-Zoom out
-Zoom Extended
-Go to time (shows time directly)
-Show time frame (Could be a special field showing the time frame)
-*
-Move up current viewer
-Move down current viewer
-Delete current viewer
-*
-Add viewer's specific insertion buttons are added here.
-
-
-Mathieu Desnoyers, June 2003
+++ /dev/null
-
-Redesign of the GUI detailed event list
-
-Mathieu Desnoyers 08/2005
-
-The basic problem about this list is that it uses the number of events, not the
-time, as a vertical axis (for the Y axis scrollbar).
-
-Seeking in the traces is done by time. We have no clue of the number of events
-between two times without doing preparsing.
-
-If we want to fully reuse textDump, it's bettwer if we depend upon state
-computation. It would be good to make the viewer work with this information
-missing though.
-
-textDump's print_field should be put in a lttv/lttv core file, so we can use it
-as is in the detailed event list module without depending upon batchAnalysis.
-
-
-* With preparsing only :
-
-The problem then becomes simpler :
-
-We can precompute the event number while doing state computation and save it
-periodically with saved states. We can then use the event number in the trace
-as scrollbar value, which, when scrolled, would result into a search in the
-saved states by event number.
-
-How much time would it take to seek back to the wanted position from the last
-saved state ?
-
-compudj@dijkstra:~/local/bin$ ./lttv -m batchtest -1 -2 -t
-/home/compudj/traces/200MB
-** Message: Processing trace while counting events (12447572 events in 14.0173
-seconds)
-** Message: Processing trace while updating state (9.46535 seconds)
-
-9.46535 s / 12447572 events * 50000 events = 0.038 s
-
-38 ms latency shouldn't be too noticeable by a user when scrolling.
-
-(note : counting events batchtest does also verify time flow integrity and get
-the position for each event (not optimal), that's why it takes 14s)
-
-As an optimisation, we could use a backing text buffer (an array of strings),
-where we would save the 50000 computed events between two consecutive saved
-states.
-
-Memory required : 50000 * 20 bytes/event = 1MB
-
-Which seems ok, but costy. In would be better, in fact, not to depend on the
-saved states interval for such a value : we could keep a 1000 events array, for
-instance (for 20KB cost, which is really better).
-
-The backing text buffer would, by itself, make sure it has a sufficient
-number of events so a scroll up/down of one page would be responded directly.
-That imply that a scroll up/down would first update the shown fields, and only
-afterward make the backing buffer resync its events in the background. In the
-case where the events were not directly available, it would have to update the
-buffer in the foreground and only then show the requested events.
-
-
-Important note : this design doesn't support filtering of events, which is
- an important downside.
-
-
-
-* If we want the viewer to be able to show information without preparsing :
-
-This is the hardest the problem could get. We have to seek by time (even the
-scrollbar must seek by time), but increment/decrement event by event when using
-the scrollbar up/down, page up/page down. Let's call them "far scroll" and "near
-scroll", respectively.
-
-A far scroll must resync the trace to the time requested by the scrollbar value.
-
-A near scroll must sync the trace to a time that is prior to the requested
-event, show the events requested, and then sync the scrollbar value (without
-event updating) to the shown event time.
-
-* seek n events backward
-
-We have no information about how far back we must request events in the trace :
-
-The algorithm would look like :
-
-seek_n_events_backward(current time, current position, time_offset, filter)
-Returns : a TracesetPosition
- - If the current time < beginning of trace, is means we cannot get any more
- events, inform the requester that a list of less than n events is ready.
- - Else, request a read to a the time_offset backward, calling the
- per event hook, and calling the after_traceset hook when finished. The end
- position would be the position of the current first event.
-
-per_event_hook
- - if filter returns true
- - Append the traceset position to a list of maximum size n. Remove the first
- entries.
-
-after_traceset_hook
- - if the list has a size less than n, invoke a seek_n_events_backward
- subsequent iteration, for completing the list. The new time_offset is the
- last time_offset used multiplied by 2. (can be done by tail recursion (if we
- want to split this operation in multiple segments) or by an iterative
- algorithm (seek_n_events_backward would be a while() calling its own
- process_traceset_middle()).
- - if the list a a size of n, it's complete : call the viewer get_print_events
- hook.
-
-
-* seek n events forward
-
-seek_n_events_forward(current position, filter)
- - Simple : seek to the current position, request read of trace calling an
- event counting hook (starts at 0).
-
-event_counting_hook
- - if filter returns true
- - increment event count.
- - if event count > requested count, inform that the current position if the
- wanted position. Return TRUE, so the read will stop.
-
-
-* Printing events
-
-get_print_events
- - seek to the position at the beginning of the list. End position is the
- current one (not in the list! the one currently shown). Call a events
- request between this positions, printing the fields to strings shown in the
- viewer.
-
-
-
-seek_n_events backward and forward seems to be interesting algorithms that
-should be implemented in the tracecontext library. With those helpers, it would
-become simpler to implement a detailed event list not depending on state
-computation.
-
-
+++ /dev/null
-Linux Trace Toolkit
-
-Mathieu Desnoyers 18-05-2004
-
-
-Seeing that a very precise hook call ordering is needed when processing events
-(especially the order for calling state update hooks and event delivery hooks),
-this document defines a new type and interface that permits to merge all kind of
-hooks, eventually sorted by the priority associated to them.
-
-- Type LttvHooks with priorities
-
-This is a modification to the actual LttvHooks that associates a priority with
-each hook. The container for this type would be a garray, just like hook.c, but
-hooks would be added at the right position in the list, by priority. Hooks in a
-hook list are ordered by priority : from highest priority (0) to
-lowest (99). The default priority is 50 (defined as LTTV_PRIO_DEFAULT).
-
-A new lttv_hooks_call_merge that will get the hooks from two hook lists in the
-right order will deal with the multiple lists priority problem.
-
-
-
-
--- /dev/null
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+ "/usr/share/sgml/docbook/dtd/4.3/xdocbook.dtd">
+<!--<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" >-->
+
+<book>
+
+<bookinfo>
+<title>Spécifications du filtre de Linux Trace Toolkit Viewer</title>
+<authorgroup>
+<author>
+<firstname>Mathieu</firstname>
+<surname>Desnoyers</surname>
+</author>
+</authorgroup>
+
+<date>26/01/2005</date>
+<releaseinfo>1.00.00</releaseinfo>
+
+<abstract>
+<para>
+Ce document décrit les spécifications requises pour la fonctionnalité de
+filtrage pour l'application
+<application>Linux Trace Toolkit Viewer</application>.
+
+</para>
+</abstract>
+
+<keywordset>
+<keyword>Linux Trace Toolkit Viewer</keyword>
+<keyword>spécification</keyword>
+<keyword>filtre</keyword>
+<keyword>specification</keyword>
+<keyword>filter</keyword>
+</keywordset>
+
+</bookinfo>
+<chapter>
+<title>Introduction</title>
+
+<para>
+Le filtre de Linux Trace Toolkit Viewer est une fonctionnalité nécessaire pour
+rendre l'outil pleinement utilisable. Des cas typiques de filtrage ont déjà été
+identifiés : filtrer par CPU ou par ID d'événement.
+</para>
+<para>
+Cependant, un utilisateur plus avancé peut vouloir filtrer selon n'importe quel
+champs d'information disponible lors de la lecture d'un événement. L'approche
+qui sera suivie, afin d'assurer l'applicabilité du filtrage aux différents types
+de traces, sera de ne pas limiter les champs selon lesquels le filtrage pourra
+être fait.
+</para>
+<para>
+Comme le filtrage se fait à la lecture de chaque événement, il peut rapidement
+devenir un goulot d'étranglement important. Les performances doivent donc être
+un souci de taille lors de la réalisation de cette fonctionnalité. C'est
+pourquoi l'architecture proposée se base sur une compilation des règles de
+filtrage lors de leur définition afin de générer une structure de données
+optimale pour le parcours de la trace.
+</para>
+<para>
+Ce document explique les différents défis à surmonter dans les différents
+sous-modules du filtre, soit : la partie "core" du filtre, qui sera intégrée,
+comme son nom l'indique, au coeur de l'application ainsi que les parties
+modulaires textes et graphiques. À la fin du document, des optimisations
+éventuelles sont énoncées, sans plus. Elles pourront être utiles dans le cas où
+les performances s'avéreraient problématiques.
+</para>
+<para>
+Ce document est le fruit d'un échange entre Michel Dagenais et moi-même, Mathieu
+Desnoyers. Certains passages sont laissés sous leur forme originale.
+</para>
+
+</chapter>
+
+
+<chapter>
+<title>Design</title>
+
+<sect1>
+<title>Core</title>
+
+<para>
+ Application des règles de filtrage aux événements. Les règles de
+ filtrage pourraient être représentées par un arbre. Cette section du
+ filtrage est assez intégrée au reste de l'application pour mériter d'être
+ au coeur même de lttv (pas dans un module séparé). Les feuilles de l'arbre
+ sont des 3-tuples (champs, relation, valeur), alors que les noeuds
+ intermédiaires sont des relations logiques (and, or, xor, not). Le and, le
+ or et le xor sont limités à deux enfants, alors que le not est limité à un
+ seul enfant.
+</para>
+<para>
+ Les champs du 3-tuple devraient respecter une arborescence qui représente
+ l'organisation des données dans les événements. Celles-ci sont, lors de la
+ lecture de la trace, accessibles via les structures :
+</para>
+<itemizedlist>
+<listitem><para>LttEvent (plus les champs spécifiques à l'événement)</para></listitem>
+<listitem><para>LttvTracefile</para></listitem>
+<listitem><para>LttvTrace</para></listitem>
+<listitem><para>LttvTraceset</para></listitem>
+<listitem><para>LttvState</para></listitem>
+</itemizedlist>
+<para>
+ On pourrait donc, au niveau de la description du champs, représenter
+ celui-ci par une chaîne de caractères imbriquable dont les niveaux sont
+ séparés par le ".". Voici la représentation des niveaux d'imbrication :
+</para>
+<para>
+<literallayout class="monospaced">
+ *
+ |->event (pour accéder aux champs sous LttEvent)
+ | |->name (string)
+ | |->category (string)
+ | |->time (LttTime)
+ | |->tsc (LttCycleCount)
+ | |->fields
+ | |->"event name"
+ | |->"field name"
+ | |->"sub-field name"
+ | |->...
+ | |->"leaf-field name" (field type)
+ |
+ |->tracefile
+ | |->name (string)
+ |->trace
+ | |->name (string)
+ |->state
+ |->pid (guint)
+ |->ppid (guint)
+ |->creation_time (LttTime)
+ |->insertion_time (LttTime)
+ |->process_name (string)
+ |->execution_mode (user_mode, syscall, trap, irq, unknown)
+ |->execution_submode (none, unknown)
+ |->process_status (wait_fork,wait_cpu,exit,zombie,wait,run,unnamed)
+ |->cpu (guint)
+</literallayout>
+</para>
+
+<para>
+L'objet contenant l'arbre des règles de filtrage ainsi que la cache du filtre,
+ qu'on pourrait appeler "LttvFilter", serait associé à une trace, non pas à un
+ trace set, pour des raisons de performance. En effet, le même nom d'événement
+ peut très bien être associé à un ID différent d'une trace à l'autre. Comme on
+ ne souhaite pas faire la translation nom->id (qui est coûteuse) à chaque
+ utilisation du filtre, on le ferait lors de sa construction. Ceci implique de
+ garder un objet LttvFilter par trace. Rien n'empêche cependant d'avoir une
+ façon de créer, au niveau usager, des filtres pour toutes les traces d'un
+ traceset, mais ceux-ci seront associés à chaque trace du trace set.
+</para>
+
+<para>
+Michel Dagenais :
+</para>
+<para>
+Je m`inquiète beaucoup pour la performance. Il faut pouvoir précompiler
+ces expressions en offset (ltt_field) et avoir un espèce d`index pour ne
+pas passer séquentiellement à travers toutes les règles et pour chaque
+règle interpréter les noms de champs à chaque événement traité!!
+</para>
+
+<para>
+Mathieu Desnoyers :
+</para>
+<para>
+C'est ce que j'avais en tête : fixer les positions des champs au moment de la
+création de la règle de filtrage, quitte à la recalculer si jamais la trace
+change en cours de route (mais ça ne devrait pas arriver, puisque les paires
+(facility, event id) sont uniques au cours d'une trace).
+</para>
+
+<para>
+Cependant, de la manière dont je vois ça, on aura pas le choix de se garder un
+arbre représentant l'expression logique et de le parcourir séquentiellement pour
+chaque événement. On peut évidemment éviter de balayer certaines branches en se
+basant sur les relations and, or, xor lors du parcours.
+</para>
+
+<para>
+Donc, je vois ça, dans le pire cas, comme un parcours infixe de l'arbre
+représentant les règles. Chaque feuille serait une règle représentée par un
+3-tuple (position, (type, relation), valeur), où chaque paire de (type,relation)
+devrait être défini pour chaque type (possiblement incorrect, comme la relation
+< sur un type string). Lors de la compilation, on passerait du 3-tuple (champs,
+relation, valeur) à un 3-tuple (position, (type, relation), valeur).
+</para>
+
+<para>
+À noter : un simple offset n'est en réalité pas assez pour représenter la
+position, puisque toutes les données ne résident pas dans une seule structure.
+Certaines sont dans le contexte (TracesetContext), d'autres dans la structure de
+l'événement. Il faut donc décrire la position, en réalité, comme une paire
+(structure, offset), où nous limitons structure aux noms de structure connus
+(qui peuvent être encodés sur la forme de GQuarks) : {LTTV_TRACE,
+LTTV_TRACEFILE, LTTV_TRACE_STATE, LTT_EVENT}.
+</para>
+
+<para>
+Lors de la compilation, on a, en entrée, le tuple :
+</para>
+
+<para>
+(champs, relation, valeur)
+</para>
+
+<para>
+où champs est un tuple : (structure, offset, type)
+</para>
+
+<para>
+On produit, en sortie, (toujours dans la même structure en arbre pour les
+expressions logiques), les 3-tuples suivants (aux feuilles) :
+</para>
+
+<para>
+(position, fonction, valeur)
+</para>
+
+<para>
+où :
+<simplelist type="inline">
+<member>position = (structure, offset)</member>
+<member>fonction = (type, relation)</member>
+</simplelist>
+</para>
+
+<para>
+Il me reste une question : que fait-on lors qu'un facility est rechargé en cours
+de traçage ? Les événements vont-ils changer d'id ?
+</para>
+
+<para>
+Michel Dagenais :
+</para>
+<para>
+Non, c`est un nouveau facility avec le même nom mais un fingerprint
+différent qui s`ajoute puisqu`il est possible que des modules utilisent
+l`ancienne version alors que d`autres utilisent la nouvelle
+simultanément. Il est possible que les règles ne spécifient que le nom
+de la facilité auquel cas elles pourraient s`appliquer à toutes les
+facilités du même nom et demanderaient d`avoir une précompilation
+différente pour chaque facilité.
+</para>
+
+<para>
+Mathieu Desnoyers :
+</para>
+<para>
+J'en conclue que le 2-tuple (facility, event id) est unique pour la trace, c'est
+ça ?
+</para>
+<para>
+Michel Dagenais :
+</para>
+<para>
+> Oui.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Module texte</title>
+
+<para>
+Lecture d'une chaîne de caractères formée d'expressions
+booléennes qui décrivent le filtre à partir des opérations de base :
+and, or, xor, not
+et de parenthèses : ( et ).
+Les entrées logiques de ce filtre sont composées 3-tuples
+(champs, relation, valeur),
+où le champs est le type d'information (i.e. pid)
+la relation est la limite sur la valeur (i.e. <)
+la valeur est la valeur qui doit être respectée par le champs selon la
+relation. Doit être du type associé au champs. À priori, on utilise
+le type de champs pour savoir sous quel type encoder l'information
+lue, tout en vérifiant le contenu de la chaîne lue pour des
+débordements (overflow) avant encodage vers le type associé.
+La lecture de cette expression booléenne formerait un arbre de règles de
+filtrage, qui serait ensuite utilisé par la partie "core" de filtrage de
+lttv pour être appliqué aux événements lors de la lecture de trace.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Module graphique</title>
+
+<para>
+Une classe filtre graphique serait associée à un arbre
+de règles de filtrage. On pourrait le modifier les objets de la classe
+filtre graphique en invoquant une fenêtre de modification de filtre qui
+permettrait d'entrer les spécifications du filtre à l'aide de champs
+graphiques de sélection (drop down list) pour les types d'éléments selon
+lesquels filtrer, et d'un champs d'entrée de texte libre pour spécifier la
+valeur que ce champs doit prendre. La relation qui doit être appliquée
+(<, >, <=, >=, =) doit être sélectionnée dans un autre drop-down list.
+En plus de la sélection graphique, l'entrée d'une chaîne de caractère serait
+possible pour spécifier le filtre selon l'entrée décrite ci-haut pour le
+module texte.
+</para>
+
+<para>
+Michel Dagenais :
+</para>
+<para>
+Oui, à la rigueur la partie graphique n`est probablement pas tellement
+plus difficile que celle textuelle. On pourrait commencer avec seulement
+la partie graphique qui produit directement la représentation en arbre.
+</para>
+
+<para>
+Mathieu Desnoyers :
+</para>
+<para>
+Comme je prévois réutiliser l'entrée texte à l'intérieur de la fenêtre
+graphique, je crois qu'il est préférable de commencer par l'entrée texte.
+D'ailleurs, l'avantage pour quelqu'un qui commence à contribuer au projet est de
+ne pas avoir à apprendre l'API de GTK en même temps qu'il fait le développement
+de son module. Il est un peu trop facile de ne pas assez découpler la logique
+interne de la présentation.
+</para>
+
+<para>
+Michel Dagenais :
+</para>
+<para>
+Le cas classique est de choisir un CPU ou un type d`événement, auquel
+cas un menu simple de CPU et type serait beaucoup plus pratique que
+d`avoir à taper une expression.
+</para>
+<para>
+Mathieu Desnoyers :
+</para>
+<para>
+On pourrait penser à faire un module graphique de création de filtre de base,
+pour les fonctionnalités les plus utilisées. Celui-ci pourra être étendu par
+la suite, si besoin est. L'intérêt est d'avoir quand-même la possibilité, pour
+un utilisateur plus avancé, de spécifier toutes les caractéristiques via
+l'interface. Dans ce cas, quelqu'un serait tout-à-fait prêt à faire une
+expression pour décrire en détail son filtre. C'est quand-même quelque chose de
+plus en plus commun avec la venue des moteurs de recherche.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Choix de syntaxe, documentation et messages d'erreur</title>
+<para>
+Michel Dagenais :
+</para>
+<para>
+Oui, une partie non négligeable est un choix de syntaxe convivial, la
+documentation et les messages d`erreur...
+</para>
+<para>
+Mathieu Desnoyers :
+</para>
+<para>
+C'est bel et bien ce qui sera perçu par l'utilisateur, de là l'importance..
+</para>
+<para>
+Je me demande s'il est mieux d'adopter une syntaxe un peu à la Google ou bien à
+la C :
+</para>
+
+<para>
+(, ), and, or, xor, not, field op value
+où op peut prendre : <, >, <=, >=, =
+</para>
+
+<para>
+ou bien à la C
+(, ), &, |, ^, !, field op value
+</para>
+
+
+<para>
+Ou bien on peut faire un alphabet mixte entre les deux, où les mots and et &
+seraient équivalents. Ce serait probablement plus facile de reconnaître les
+symboles comme & par contre, et moins limitant sur le traitement du mot
+identifiant le field.
+</para>
+
+<para>
+Mais cette question est de moindre importance : tant qu'on se fixe un standard
+et qu'on le documente, je crois qu'il n'y a pas vraiment de mauvais choix.
+</para>
+
+<para>
+Pour la documentation, l'ajout d'une section au guide de l'utilisateur (déjà en
+docbook) me semble très adéquat.
+</para>
+
+<para>
+Pour les messages d'erreur, il faudra entres autres penser à valider les
+opération par rapport à celles permises pour chaque type. Par exemple, un > n'a
+pas vraiment de sens pour un string.
+</para>
+
+
+<para>
+Michel Dagenais :
+</para>
+<para>
+Je tendrais à prendre la syntaxe C.
+</para>
+
+<para>
+Mathieu Desnoyers :
+</para>
+<para>
+Si on utilise de manière stricte la syntaxe C, il faudrait utiliser ceci :
+</para>
+
+<para>
+&&, ||, ==, (rien pour le xor logique ?)
+</para>
+
+<para>
+Je me dis que, puisque nous n'avons pas besoin des opérations "bitwise", nous
+pourrions utiliser celles-ci.
+</para>
+
+<para>
+Donc, ce que je propose, est d'utiliser l'alphabet utilisé pour les opérateurs
+bitwise du C en tant qu'opérateurs logiques pour notre parser d'expressions de
+filtre :
+</para>
+
+<para>
+&, |, =, ^
+</para>
+
+<para>
+Ceci est un détail sémantique, mais je veux juste m'assurer qu'on est d'accord.
+</para>
+
+
+</sect1>
+
+<sect1>
+<title>Optimisation éventuelles</title>
+
+
+<para>
+ "Cache" de filtre, afin d'optimiser le cas courant.
+ Au niveau de la partie "core" du filtrage, on pourrait faire une hash
+ table indexée par une clé formée d'un xor des champs à filtrer. Alors, si un
+ événement possède les même caractéristiques de filtrage, on pourrait accéder à
+ la solution (V/F) en O(1). Le coût est de calculer la clé de hashage pour
+ chaque événement. L'avantage apparaît lorsqu'il y a plusieurs critères de
+ filtrage à comparer. La remise à zéro de cette cache devrait être faite
+ lorsqu'il y a des modifications au filtre.
+</para>
+
+<para>
+Michel Dagenais :
+</para>
+<para>
+Les travaux sur l`optimisation de requêtes dans les bases de données est
+probablement pertinent pour ce genre de choses.
+</para>
+
+<para>
+Mathieu Desnoyers :
+</para>
+<para>
+Il faudra que je m'y arrête. Cependant, ceci constitue une optimisation et n'est
+donc pas crucial pour le fonctionnement.
+</para>
+
+
+<para>
+Michel Dagenais :
+</para>
+<para>
+Sauf si c`est inutilisable sans une telle optimisation :-).
+</para>
+
+<para>
+Mathieu Desnoyers :
+</para>
+<para>
+N'est-ce pas toi qui m'a déjà dit, citant Donald Knuth : "Premature
+optimisation is the root of all evil" ? :)
+</para>
+
+<para>
+Effectivement, si on s'aperçoit que c'est trop lent, il faudra passer à cette
+étape.
+</para>
+
+
+</sect1>
+
+</chapter>
+
+
+
+</book>
--- /dev/null
+GUI Layout
+
+
+
+
+In order to implement the GUI, choices has to be made based on habitual interfaces that we know users are familiar with. The inspiration for these choices came mainly from the Mozilla browser project and also from Openoffice, which are currently used as two userfriendly applications in various Linux distribution at the time of this writing.
+
+This document describes the layout of the GUI in three sections : containers, menus and toolbars.
+
+A status bar is also placed at the bottom of the window.
+
+- Containers
+
+elements hierarchy
+
+Window Mainwindow
+|->vbox
+ |->menus
+ |->toolbar of the main window
+ |->toolbar of the currently selected viewer
+ |->notebook
+ | |->vpaned
+ | |->viewer's widget
+ | |->vpaned
+ | |->viewer's widget
+ | |->vpaned
+ | |->...
+ |->Status bar
+
+- Menus
+
+Here is a short description of each menu entry
+* by itself means a separator
+
+
+- File
+*New -> *Empty trace set : open a new window with an empty trace set.
+ *Clone trace set : copy the content of the current window in a new
+ window.
+ *
+ *Tab : Opens a new tab.
+*Open : open a trace set. Calls a file selection dialog.
+*Close : close the current window.
+*Close Tab : close the current tab.
+*
+*Add trace : Add a trace to the window's traceset. Calls file selection dialog.
+*Remove trace : Removes a trace from the traceset.
+*Save : save the trace set. Calls a file save dialog of no current filename.
+*Save as : save a trace set. Calls a file save dialog.
+*
+*Quit : quit the program.
+
+- Edit ? (not needed for now)
+
+- View
+*Zoom In : Multiply the zoom factor by a certain quantity.
+*Zoom Out : Divide the zoom factor by a certain quantity.
+*Zoom Extended : Show the entire traceset's largest time interval.
+*Go to time : Keep same zoom, ask user for time to center view on and make
+ it the current time.
+*Show time frame : ask user for time interval to show.
+ (modify zoom and current event in consequence)
+
+- Tools (this is an example of how viewer's menu entries should look like)
+*Move viewer up -> Moves the current viewer up one position.
+*Move viewer down -> Moves the current viewer down one position.
+*Remove : remove the current viewer
+*
+*DumpToFile -> *Dump Text (This is a text module which adds graphical menu
+ entries)
+ *Dump binary
+* (separator between text tools and graphical tools implies different function
+ to register each type of menu entries)
+*Insert Events View : insert this type of viewer
+*Insert ControlFlow View
+- Plugins
+*Load module : ask the user a module to load (list modules in search path).
+*Unload module : list all modules, click to choose, then unload button.
+*Add module search path : ask user for a new path (file selection dialog).
+
+- Options
+//FIXME *Color : change the color of the currently selected element ?
+*Filter : Show traceset's filter option window.
+*Save configuration : Save the currently loaded modules/traceset/filters
+ to gconf.
+
+
+(aligned to the right)
+- Help
+*Content
+*About
+
+
+- Toolbar
+
+The toolbar is separated in two parts : like the two lines used in Openoffice. The first one is applying to the top level window (or current tab) while the one below contains the current viewer's toolbar.
+
+So we have something like this :
+
+--------------------------------------------------------------------------------
+| Menus |
+--------------------------------------------------------------------------------
+| Toolbar of the top level window |
+--------------------------------------------------------------------------------
+| Toolbar of the current viewer |
+--------------------------------------------------------------------------------
+||Current Tab| |
+|-----------------------------------------------------------------------------||
+||viewers in vpaned ||
+|| ||
+||----------------------------------------------------------------------------||
+--------------------------------------------------------------------------------
+| Status bar |
+--------------------------------------------------------------------------------
+
+
+The toolbar of the top level window is the only one described in this document, as the second one is defined by the viewers and specific to each of them.
+
+This toolbar is mainly a selection of the menu entries.
+
+New : New window with empty trace set.
+Open : open a trace set.
+Add Trace
+Remove Trace
+Save : save the current trace set.
+Save as
+*
+Zoom in
+(Show the current zoom factor, modifiable)
+Zoom out
+Zoom Extended
+Go to time (shows time directly)
+Show time frame (Could be a special field showing the time frame)
+*
+Move up current viewer
+Move down current viewer
+Delete current viewer
+*
+Add viewer's specific insertion buttons are added here.
+
+
+Mathieu Desnoyers, June 2003
--- /dev/null
+
+Redesign of the GUI detailed event list
+
+Mathieu Desnoyers 08/2005
+
+The basic problem about this list is that it uses the number of events, not the
+time, as a vertical axis (for the Y axis scrollbar).
+
+Seeking in the traces is done by time. We have no clue of the number of events
+between two times without doing preparsing.
+
+If we want to fully reuse textDump, it's bettwer if we depend upon state
+computation. It would be good to make the viewer work with this information
+missing though.
+
+textDump's print_field should be put in a lttv/lttv core file, so we can use it
+as is in the detailed event list module without depending upon batchAnalysis.
+
+
+* With preparsing only :
+
+The problem then becomes simpler :
+
+We can precompute the event number while doing state computation and save it
+periodically with saved states. We can then use the event number in the trace
+as scrollbar value, which, when scrolled, would result into a search in the
+saved states by event number.
+
+How much time would it take to seek back to the wanted position from the last
+saved state ?
+
+compudj@dijkstra:~/local/bin$ ./lttv -m batchtest -1 -2 -t
+/home/compudj/traces/200MB
+** Message: Processing trace while counting events (12447572 events in 14.0173
+seconds)
+** Message: Processing trace while updating state (9.46535 seconds)
+
+9.46535 s / 12447572 events * 50000 events = 0.038 s
+
+38 ms latency shouldn't be too noticeable by a user when scrolling.
+
+(note : counting events batchtest does also verify time flow integrity and get
+the position for each event (not optimal), that's why it takes 14s)
+
+As an optimisation, we could use a backing text buffer (an array of strings),
+where we would save the 50000 computed events between two consecutive saved
+states.
+
+Memory required : 50000 * 20 bytes/event = 1MB
+
+Which seems ok, but costy. In would be better, in fact, not to depend on the
+saved states interval for such a value : we could keep a 1000 events array, for
+instance (for 20KB cost, which is really better).
+
+The backing text buffer would, by itself, make sure it has a sufficient
+number of events so a scroll up/down of one page would be responded directly.
+That imply that a scroll up/down would first update the shown fields, and only
+afterward make the backing buffer resync its events in the background. In the
+case where the events were not directly available, it would have to update the
+buffer in the foreground and only then show the requested events.
+
+
+Important note : this design doesn't support filtering of events, which is
+ an important downside.
+
+
+
+* If we want the viewer to be able to show information without preparsing :
+
+This is the hardest the problem could get. We have to seek by time (even the
+scrollbar must seek by time), but increment/decrement event by event when using
+the scrollbar up/down, page up/page down. Let's call them "far scroll" and "near
+scroll", respectively.
+
+A far scroll must resync the trace to the time requested by the scrollbar value.
+
+A near scroll must sync the trace to a time that is prior to the requested
+event, show the events requested, and then sync the scrollbar value (without
+event updating) to the shown event time.
+
+* seek n events backward
+
+We have no information about how far back we must request events in the trace :
+
+The algorithm would look like :
+
+seek_n_events_backward(current time, current position, time_offset, filter)
+Returns : a TracesetPosition
+ - If the current time < beginning of trace, is means we cannot get any more
+ events, inform the requester that a list of less than n events is ready.
+ - Else, request a read to a the time_offset backward, calling the
+ per event hook, and calling the after_traceset hook when finished. The end
+ position would be the position of the current first event.
+
+per_event_hook
+ - if filter returns true
+ - Append the traceset position to a list of maximum size n. Remove the first
+ entries.
+
+after_traceset_hook
+ - if the list has a size less than n, invoke a seek_n_events_backward
+ subsequent iteration, for completing the list. The new time_offset is the
+ last time_offset used multiplied by 2. (can be done by tail recursion (if we
+ want to split this operation in multiple segments) or by an iterative
+ algorithm (seek_n_events_backward would be a while() calling its own
+ process_traceset_middle()).
+ - if the list a a size of n, it's complete : call the viewer get_print_events
+ hook.
+
+
+* seek n events forward
+
+seek_n_events_forward(current position, filter)
+ - Simple : seek to the current position, request read of trace calling an
+ event counting hook (starts at 0).
+
+event_counting_hook
+ - if filter returns true
+ - increment event count.
+ - if event count > requested count, inform that the current position if the
+ wanted position. Return TRUE, so the read will stop.
+
+
+* Printing events
+
+get_print_events
+ - seek to the position at the beginning of the list. End position is the
+ current one (not in the list! the one currently shown). Call a events
+ request between this positions, printing the fields to strings shown in the
+ viewer.
+
+
+
+seek_n_events backward and forward seems to be interesting algorithms that
+should be implemented in the tracecontext library. With those helpers, it would
+become simpler to implement a detailed event list not depending on state
+computation.
+
+
--- /dev/null
+Linux Trace Toolkit
+
+Mathieu Desnoyers 18-05-2004
+
+
+Seeing that a very precise hook call ordering is needed when processing events
+(especially the order for calling state update hooks and event delivery hooks),
+this document defines a new type and interface that permits to merge all kind of
+hooks, eventually sorted by the priority associated to them.
+
+- Type LttvHooks with priorities
+
+This is a modification to the actual LttvHooks that associates a priority with
+each hook. The container for this type would be a garray, just like hook.c, but
+hooks would be added at the right position in the list, by priority. Hooks in a
+hook list are ordered by priority : from highest priority (0) to
+lowest (99). The default priority is 50 (defined as LTTV_PRIO_DEFAULT).
+
+A new lttv_hooks_call_merge that will get the hooks from two hook lists in the
+right order will deal with the multiple lists priority problem.
+
+
+
+
--- /dev/null
+Linux Trace Toolkit
+
+Mathieu Desnoyers 17-05-2004
+
+
+1. Read Requests Cases Study
+
+The goal of this document is to describe the typical behavior of viewers when
+they request data to a process traceset. After the implementation of three
+viewers, with different needs, the idea of their need for a trace processing API
+is getting clearer. We then describe a new API for process traceset that would
+better suits the needs of those viewers.
+
+They are splitted in two different categories : the first one is the one where
+the viewers select the events they need by specifying a time interval in the
+traceset and the second one is where the viewers specify a start event by its
+position in the traceset and a certain amount of events it needs.
+
+This is a simplified case study : we look at the direct interaction between
+graphical viewers and process traceset, without the main window as a negociator.
+
+Control Flow Viewer
+
+This viewer, consisting in a two dimensions graph, shows the different processes
+as its y axis and the time as x axis. It's clear that it needs to get the events
+by specifying a start time and an end time, constituing a time interval.
+
+
+Detailed Events List
+
+This list has nothing to do with time : it shows the events one by one. It cares
+about the quantity of events, not their time.
+
+It would be simple to get the events one by one if we were reading only one
+tracefile (one cpu), but the way events are read through each trace
+(monothically increasing time) makes it a little bit more difficult to specify
+how to increment event position. We will determine how it could be done simply.
+
+Let's define an event position. It's a pointer to a position into each
+tracefile. It's only meaningful when associated with a context. Comparisons
+between positions are done by looking comparing saved positions for each
+tracefile, until a difference is found.
+
+A viewer could use a start time as a start event. It would specify a number of
+events it needs. As a first call, it could ask for the start time of the
+traceset. Afterward, it can save the position of the context after the last
+event has been delivered in its after traceset function.
+
+Now, let's see how process traceset could handle it. It would seek in the
+traceset, searching the position number.
+(need a new lttv_process_traceset_seek_position)
+
+Then, the viewer could simply call a process traceset middle function
+specifying a number of events to get.
+
+The whole concept of numbering events would be hidden in the order in which the
+process traceset gets the events in a monothically increasing time.
+
+
+
+2. Architecture
+
+API to seek/read traceset will be extended to fully support both start time,
+start position, end time, end position and number of events as possible
+boundaries for reading.
+
+lttv_process_traceset_seek_time
+lttv_process_traceset_seek_position
+
+lttv_process_traceset_middle
+
+It must be modified to end when it encounters the first criterion : number of
+events to read reached, end time reached, end position reached.
+
+lttv_traceset_context_position_save
+
+The position_save saves a position that can be used later to seek back to this
+exact same position, with event granularity. This implies that the
+process_traceset must deliver events with the same timestamp in a deterministic
+manner. This is actually done by using tracefile and trace numbers in the
+context in the comparison function.
+
+
+
+Description of new context API useage
+
+1. seek
+2. begin -> add middle hooks
+ -> call begin hooks by id
+3. middle -> call middle hooks by id
+4. end -> call end hooks by id
+ -> remove middle hooks
+
+3. Impact on State
+
+From now on, the state computation will be done in the middle hook call, with a
+priority higher than default. We will define this priority as PRIO_STATE,
+defined to 25.
+
+If state has to be computed, lttv_process_traceset_begin has to be called in
+a first time. It adds the state hooks to the context. Then, the state
+seek_closest will have to be used to restore the nearest state, plus a
+process_traceset with no hooks present other than the state hooks will have to
+be called to go from the closest state to the real time seeked.
+
+The lttv_process_traceset_end will only need to be called if no further state
+computation is needed.
+
+
+4. Implementation in tracecontext.c
+
+
+- Type LttvTracesetContextPosition
+
+struct _LttvTraceContextPosition {
+ LttEventPosition *tf_pos; /* Position in each trace */
+ guint nb_tracefile; /* Number of tracefiles (check) */
+}
+
+struct _LttvTracesetContextPosition {
+ LttTraceContextPosition *t_pos; /* Position in each trace */
+ guint nb_trace; /* Number of traces (check) */
+}
+
+with interfaces :
+
+lttv_traceset_context_position_save
+(const LttvTracesetContext *context,
+ LttvTracesetContextPosition *pos);
+
+
+Dependencies :
+
+- lttv_process_traceset_seek_position(LttvTracesetContext *self,
+ const LttvTracesetContextPosition *position);
+ - ltt_tracefile_seek_position : already implemented
+
+lttv_process_traceset_seek_position will seek each tracefile to the right
+position. We keep information about number of tracefiles for extra integrity
+checking when reloading the position in the context. It also loads the pqueue.
+
+
+
+- lttv_process_traceset_middle
+We modify lttv_process_traceset_middle so that it takes as arguments :
+(LttvTracesetContext *self,
+LttTime end,
+unsigned nb_events,
+const LttvTracesetContextPosition *end_position)
+
+This new version of process traceset middle will call the event hooks for
+events until the first criterion is fulfilled : either the end time is reached,
+the number of events requested is passed, the end position is reached or the
+last event hook list called returned TRUE. When this function ends, the end
+position can be extracted from the context, the end event is set as described
+below and the number of events read is returned.
+
+The end event is a pointer to the last event the hooks has been called for.
+
+- lttv_process_traceset_seek_time : already implemented
+ - now loads the pqueue.
+
+- lttv_process_traceset_begin(LttvTracesetContext *self,
+ LttvHooks *before_traceset,
+ LttvHooks *before_trace,
+ LttvHooks *before_tracefile,
+ LttvHooks *event,
+ LttvHooksById *event_by_id)
+
+
+- lttv_process_traceset_end(LttvTracesetContext *self,
+ LttvHooks *after_traceset,
+ LttvHooks *after_trace,
+ LttvHooks *after_tracefile,
+ LttvHooks *event,
+ LttvHooksById *event_by_id)
+
+- lttv_traceset_context_add_hooks and lttv_traceset_context_remove_hooks
+
+These functions now become internal to tracecontext.c
+
+
+
+
--- /dev/null
+Linux Trace Toolkit
+
+Requests Servicing Schedulers
+
+
+Mathieu Desnoyers, 07/06/2004
+
+
+In the LTT graphical interface, two main types of events requests may occur :
+
+- events requests made by a viewer concerning a traceset for a ad hoc
+ computation.
+- events requests made by a viewer concerning a trace for a precomputation.
+
+
+Ad Hoc Computation
+
+The ad hoc computation must be serviced immediately : they are directly
+responding to events requests that must be serviced to complete the graphical
+widgets'data. This kind of computation may lead to incomplete result as long as
+precomputation are not finished. Once precomputation is over, the widgets will
+be redrawn if they needed such information. A ad hoc computation is done on a
+traceset : the workspace of a tab.
+
+Precomputation
+
+Traces are global objects. Only one instance of a trace is opened for all the
+program. Precomputation will append data to the traces attributes (states,
+statistics). It must inform the widgets which asked for such states or
+statistics of their availability. Only one precomputation must be launched for
+each trace and no duplication of precomputation must be done.
+
+
+Schedulers
+
+There is one tracesetcontext per traceset. Each reference to a trace by a
+traceset also has its own tracecontext. Each trace, by itself, has its own
+tracecontext.
+
+Let's define a scheduler as a g_idle events request servicing function.
+
+There is one scheduler per traceset context (registered when there are requests
+to answer). There is also one scheduler per autonomous trace context (not
+related to any traceset context).
+
+A scheduler processes requests for a specific traceset or trace by combining
+time intervals of the requests. It is interruptible by any GTK event. A
+precomputation scheduler has a lower priority than a ad hoc computation
+scheduler. That means that no precomputation will be performed until there is
+no more ad hoc compuation pending. When a scheduler is interrupted, it makes no
+assumption about the presence or absence of the current requests in its pool
+when it starts back.
+
+
+Foreground Scheduler
+
+There can be one foreground scheduler per traceset (one traceset per tab). It
+simply calls the hooks given by the events requests of the viewers for the
+specified time intervals.
+
+
+Background Scheduler
+
+Right now, to simplify the problem of the background scheduler, we assume that
+the module that loads the extended statistics hooks has been loaded before the
+data is requested and that it is not unloaded until the program stops. We will
+eventually have to deal with the requests removal based on module load/unload,
+but it complicates the problem quite a bit.
+
+A background scheduler adds hooks located under a global attributes path
+(specified by the viewer who makes the request) to the trace's traceset
+context (the trace is specified by the viewer). Then, it processes the whole
+trace with this context (and hooks).
+
+Typically, a module that extends statistics will register hooks in the global
+attributes tree under /computation/modulename/hook_name . A viewer
+that needs these statistics for a set of traces does a background computation
+request through a call to the main window API function. It must specify all
+types of hooks that must be called for the specified trace.
+
+The background computation requests for a trace are queued. When the idle
+function kicks in to answer these requests, it add the hooks of all the requests
+toghether in the context and starts the read. It also keeps a list of the
+background requests currently serviced.
+
+The read is done from start to end of the trace, calling all the hooks present
+in the context. Only when the read is over, the after_request hooks of the
+currently serviced requests are called and the requests are destroyed.
+
+If there are requests in the waiting queue, they are all added to the current
+pool and processed. It is important to understand that, while a processing is in
+being done, no requests are added to the pool : they wait for their turn in the
+queue.
+
+Every hook that are added to the context by the scheduler comes from global
+attributes, i.e.
+/traces/#
+ in LttvTrace attributes : modulename/hook_name
+
+They come with a flag telling either in_progress or ready. If the flag
+ready is set, a viewer knows that the data it needs is already ready and he
+doesn't have to make a request.
+
+If the flag in_progress is set, that means that the data it needs is currently
+being serviced, and it must wait for the current servicing to be finished. It
+tells the lttvwindow API to call a hook when the actual servicing is over (there
+is a special function for this, as it requires to modify the pool of requests
+actually being serviced : we must make sure that no new reading hooks are
+added!).
+
+
+
+
+
+New Global Attributes
+
+/traces/#
+ in LttvTrace attributes :
+
+When a processing is fired, a variable
+ computation/modulename/in_progress is set.
+
+When a processing finished, a variable
+ computation/modulename/in_progress is unset
+ computation/modulename/ready is set
+
+
+
+
+
+Typical Use For a Viewer
+
+When a viewer wants extended information, it must first check if it is ready.
+if not :
+Before a viewer makes a request, it must check the in_progress status of the
+hooks.
+
+If the in_progress is unset, it makes the request.
+
+If the in_progress is set, it makes a special request for being informed of the
+end of request.
+
+
+
+
+Hooks Lists
+
+In order to answer the problems of background processing, we need to add a
+reference counter for each hook of a hook list. If the same hook is added twice,
+it will be called only once, but it will need two "remove" to be really removed
+from the list. Two hooks are identical if they have the same function pointer
+and hook_data.
+
+
+
+
+
+
+Implementation
+
+Ad Hoc Computation
+
+see lttvwindow_events_delivery.txt
+
+
+Hooks Lists
+
+need new ref_count field with each hook
+lttv_hook_add and lttv_hook_add_list must compare addition with present and
+increment ref counter if already present.
+
+lttv_hook_remove and remove_with_data must decrement ref_count is >1, or remove
+the element otherwise (==1).
+
+
+
+Background Scheduler
+
+Global traces
+
+Two global attributes per trace :
+traces/#
+ It is a pointer to the LttvTrace structure.
+ In the LttvTrace attributes :
+ state/
+ saved_states/
+ statistics/
+ modes/
+ cpu/
+ processes/
+ modulename1/
+ modulename2/
+ ...
+ computation/ /* Trace specific background computation hooks status */
+ state/
+ in_progress
+ ready
+ stats/
+ in_progress
+ ready
+ modulename1/
+ in_progress
+ ready
+ requests_queue/ /* Background computation requests */
+ requests_current/ /* Type : BackgroundRequest */
+ notify_queue/
+ notify_current/
+ computation_traceset/
+ computation_traceset_context/
+
+
+computation/ /* Global background computation hooks */
+ state/
+ before_chunk_traceset
+ before_chunk_trace
+ before_chunk_tracefile
+ after_...
+ before_request
+ after_request
+ event_hook
+ event_hook_by_id
+ hook_adder
+ hook_remover
+ stats/
+ ...
+ modulename1/
+ ...
+
+Hook Adder and Hook remover
+
+Hook functions that takes a trace context as call data. They simply
+add / remove the computation related hooks from the trace context.
+
+
+
+Modify Traceset
+Points to the global traces. Main window must open a new one only when no
+instance of the pathname exists.
+
+Modify trace opening / close to make them create and destroy
+LttvBackgroundComputation (and call end requests hooks for servicing requests)
+and global trace info when references to the trace is zero.
+
+
+
+EventsRequest Structure
+
+This structure is the element of the events requests pools. The owner field is
+used as an ownership identifier. The viewer field is a pointer to the data
+structure upon which the action applies. Typically, both will be pointers to
+the viewer's data structure.
+
+In a ad hoc events request, a pointer to the EventsRequest structure is used as
+hook_data in the hook lists : it must have been added by the viewers.
+
+
+Modify module load/unload
+
+A module that registers global computation hooks in the global attributes upon
+load should unregister them when unloaded. Also, it must remove every background
+computation request for each trace that has its own module_name as GQuark.
+
+
+Give an API for calculation modules
+
+Must have an API for module which register calculation hooks. Unregistration
+must also remove all requests made for these hooks.
+
+
+Background Requests Servicing Algorithm (v1)
+
+
+list_in : currently serviced requests
+list_out : queue of requests waiting for processing
+
+notification lists :
+notify_in : currently checked notifications
+notify_out : queue of notifications that comes along with next processing.
+
+
+0.1 Lock traces
+0.2 Sync tracefiles
+
+1. Before processing
+ - if list_in is empty
+ - Add all requests in list_out to list_in, empty list_out
+ - for each request in list_in
+ - set hooks'in_progress flag to TRUE
+ - call before request hook
+ - seek trace to start
+ - Move all notifications from notify_out to notify_in.
+ - for each request in list_in
+ - Call before chunk hooks for list_in
+ - add hooks to context *note only one hook of each type added.
+
+2. call process traceset middle for a chunk
+ (assert list_in is not empty! : should not even be called in that case)
+
+3. After the chunk
+ 3.1 call after_chunk hooks for list_in
+ - for each request in list_in
+ - Call after chunk hooks for list_in
+ - remove hooks from context *note : only one hook of each type
+ 3.2 for each notify_in
+ - if current time >= notify time, call notify and remove from notify_in
+ - if current position >= notify position, call notify and remove from
+ notify_in
+ 3.3 if end of trace reached
+ - for each request in list_in
+ - set hooks'in_progress flag to FALSE
+ - set hooks'ready flag to TRUE
+ - call after request hook
+ - remove request
+ - for each notifications in notify_in
+ - call notify and remove from notify_in
+ - reset the context
+ - if list_out is empty
+ return FALSE (scheduler stopped)
+ - else
+ return TRUE (scheduler still registered)
+ 3.4 else
+ - return TRUE (scheduler still registered)
+
+4. Unlock traces
+++ /dev/null
-Linux Trace Toolkit
-
-Mathieu Desnoyers 17-05-2004
-
-
-1. Read Requests Cases Study
-
-The goal of this document is to describe the typical behavior of viewers when
-they request data to a process traceset. After the implementation of three
-viewers, with different needs, the idea of their need for a trace processing API
-is getting clearer. We then describe a new API for process traceset that would
-better suits the needs of those viewers.
-
-They are splitted in two different categories : the first one is the one where
-the viewers select the events they need by specifying a time interval in the
-traceset and the second one is where the viewers specify a start event by its
-position in the traceset and a certain amount of events it needs.
-
-This is a simplified case study : we look at the direct interaction between
-graphical viewers and process traceset, without the main window as a negociator.
-
-Control Flow Viewer
-
-This viewer, consisting in a two dimensions graph, shows the different processes
-as its y axis and the time as x axis. It's clear that it needs to get the events
-by specifying a start time and an end time, constituing a time interval.
-
-
-Detailed Events List
-
-This list has nothing to do with time : it shows the events one by one. It cares
-about the quantity of events, not their time.
-
-It would be simple to get the events one by one if we were reading only one
-tracefile (one cpu), but the way events are read through each trace
-(monothically increasing time) makes it a little bit more difficult to specify
-how to increment event position. We will determine how it could be done simply.
-
-Let's define an event position. It's a pointer to a position into each
-tracefile. It's only meaningful when associated with a context. Comparisons
-between positions are done by looking comparing saved positions for each
-tracefile, until a difference is found.
-
-A viewer could use a start time as a start event. It would specify a number of
-events it needs. As a first call, it could ask for the start time of the
-traceset. Afterward, it can save the position of the context after the last
-event has been delivered in its after traceset function.
-
-Now, let's see how process traceset could handle it. It would seek in the
-traceset, searching the position number.
-(need a new lttv_process_traceset_seek_position)
-
-Then, the viewer could simply call a process traceset middle function
-specifying a number of events to get.
-
-The whole concept of numbering events would be hidden in the order in which the
-process traceset gets the events in a monothically increasing time.
-
-
-
-2. Architecture
-
-API to seek/read traceset will be extended to fully support both start time,
-start position, end time, end position and number of events as possible
-boundaries for reading.
-
-lttv_process_traceset_seek_time
-lttv_process_traceset_seek_position
-
-lttv_process_traceset_middle
-
-It must be modified to end when it encounters the first criterion : number of
-events to read reached, end time reached, end position reached.
-
-lttv_traceset_context_position_save
-
-The position_save saves a position that can be used later to seek back to this
-exact same position, with event granularity. This implies that the
-process_traceset must deliver events with the same timestamp in a deterministic
-manner. This is actually done by using tracefile and trace numbers in the
-context in the comparison function.
-
-
-
-Description of new context API useage
-
-1. seek
-2. begin -> add middle hooks
- -> call begin hooks by id
-3. middle -> call middle hooks by id
-4. end -> call end hooks by id
- -> remove middle hooks
-
-3. Impact on State
-
-From now on, the state computation will be done in the middle hook call, with a
-priority higher than default. We will define this priority as PRIO_STATE,
-defined to 25.
-
-If state has to be computed, lttv_process_traceset_begin has to be called in
-a first time. It adds the state hooks to the context. Then, the state
-seek_closest will have to be used to restore the nearest state, plus a
-process_traceset with no hooks present other than the state hooks will have to
-be called to go from the closest state to the real time seeked.
-
-The lttv_process_traceset_end will only need to be called if no further state
-computation is needed.
-
-
-4. Implementation in tracecontext.c
-
-
-- Type LttvTracesetContextPosition
-
-struct _LttvTraceContextPosition {
- LttEventPosition *tf_pos; /* Position in each trace */
- guint nb_tracefile; /* Number of tracefiles (check) */
-}
-
-struct _LttvTracesetContextPosition {
- LttTraceContextPosition *t_pos; /* Position in each trace */
- guint nb_trace; /* Number of traces (check) */
-}
-
-with interfaces :
-
-lttv_traceset_context_position_save
-(const LttvTracesetContext *context,
- LttvTracesetContextPosition *pos);
-
-
-Dependencies :
-
-- lttv_process_traceset_seek_position(LttvTracesetContext *self,
- const LttvTracesetContextPosition *position);
- - ltt_tracefile_seek_position : already implemented
-
-lttv_process_traceset_seek_position will seek each tracefile to the right
-position. We keep information about number of tracefiles for extra integrity
-checking when reloading the position in the context. It also loads the pqueue.
-
-
-
-- lttv_process_traceset_middle
-We modify lttv_process_traceset_middle so that it takes as arguments :
-(LttvTracesetContext *self,
-LttTime end,
-unsigned nb_events,
-const LttvTracesetContextPosition *end_position)
-
-This new version of process traceset middle will call the event hooks for
-events until the first criterion is fulfilled : either the end time is reached,
-the number of events requested is passed, the end position is reached or the
-last event hook list called returned TRUE. When this function ends, the end
-position can be extracted from the context, the end event is set as described
-below and the number of events read is returned.
-
-The end event is a pointer to the last event the hooks has been called for.
-
-- lttv_process_traceset_seek_time : already implemented
- - now loads the pqueue.
-
-- lttv_process_traceset_begin(LttvTracesetContext *self,
- LttvHooks *before_traceset,
- LttvHooks *before_trace,
- LttvHooks *before_tracefile,
- LttvHooks *event,
- LttvHooksById *event_by_id)
-
-
-- lttv_process_traceset_end(LttvTracesetContext *self,
- LttvHooks *after_traceset,
- LttvHooks *after_trace,
- LttvHooks *after_tracefile,
- LttvHooks *event,
- LttvHooksById *event_by_id)
-
-- lttv_traceset_context_add_hooks and lttv_traceset_context_remove_hooks
-
-These functions now become internal to tracecontext.c
-
-
-
-
+++ /dev/null
-Linux Trace Toolkit
-
-Requests Servicing Schedulers
-
-
-Mathieu Desnoyers, 07/06/2004
-
-
-In the LTT graphical interface, two main types of events requests may occur :
-
-- events requests made by a viewer concerning a traceset for a ad hoc
- computation.
-- events requests made by a viewer concerning a trace for a precomputation.
-
-
-Ad Hoc Computation
-
-The ad hoc computation must be serviced immediately : they are directly
-responding to events requests that must be serviced to complete the graphical
-widgets'data. This kind of computation may lead to incomplete result as long as
-precomputation are not finished. Once precomputation is over, the widgets will
-be redrawn if they needed such information. A ad hoc computation is done on a
-traceset : the workspace of a tab.
-
-Precomputation
-
-Traces are global objects. Only one instance of a trace is opened for all the
-program. Precomputation will append data to the traces attributes (states,
-statistics). It must inform the widgets which asked for such states or
-statistics of their availability. Only one precomputation must be launched for
-each trace and no duplication of precomputation must be done.
-
-
-Schedulers
-
-There is one tracesetcontext per traceset. Each reference to a trace by a
-traceset also has its own tracecontext. Each trace, by itself, has its own
-tracecontext.
-
-Let's define a scheduler as a g_idle events request servicing function.
-
-There is one scheduler per traceset context (registered when there are requests
-to answer). There is also one scheduler per autonomous trace context (not
-related to any traceset context).
-
-A scheduler processes requests for a specific traceset or trace by combining
-time intervals of the requests. It is interruptible by any GTK event. A
-precomputation scheduler has a lower priority than a ad hoc computation
-scheduler. That means that no precomputation will be performed until there is
-no more ad hoc compuation pending. When a scheduler is interrupted, it makes no
-assumption about the presence or absence of the current requests in its pool
-when it starts back.
-
-
-Foreground Scheduler
-
-There can be one foreground scheduler per traceset (one traceset per tab). It
-simply calls the hooks given by the events requests of the viewers for the
-specified time intervals.
-
-
-Background Scheduler
-
-Right now, to simplify the problem of the background scheduler, we assume that
-the module that loads the extended statistics hooks has been loaded before the
-data is requested and that it is not unloaded until the program stops. We will
-eventually have to deal with the requests removal based on module load/unload,
-but it complicates the problem quite a bit.
-
-A background scheduler adds hooks located under a global attributes path
-(specified by the viewer who makes the request) to the trace's traceset
-context (the trace is specified by the viewer). Then, it processes the whole
-trace with this context (and hooks).
-
-Typically, a module that extends statistics will register hooks in the global
-attributes tree under /computation/modulename/hook_name . A viewer
-that needs these statistics for a set of traces does a background computation
-request through a call to the main window API function. It must specify all
-types of hooks that must be called for the specified trace.
-
-The background computation requests for a trace are queued. When the idle
-function kicks in to answer these requests, it add the hooks of all the requests
-toghether in the context and starts the read. It also keeps a list of the
-background requests currently serviced.
-
-The read is done from start to end of the trace, calling all the hooks present
-in the context. Only when the read is over, the after_request hooks of the
-currently serviced requests are called and the requests are destroyed.
-
-If there are requests in the waiting queue, they are all added to the current
-pool and processed. It is important to understand that, while a processing is in
-being done, no requests are added to the pool : they wait for their turn in the
-queue.
-
-Every hook that are added to the context by the scheduler comes from global
-attributes, i.e.
-/traces/#
- in LttvTrace attributes : modulename/hook_name
-
-They come with a flag telling either in_progress or ready. If the flag
-ready is set, a viewer knows that the data it needs is already ready and he
-doesn't have to make a request.
-
-If the flag in_progress is set, that means that the data it needs is currently
-being serviced, and it must wait for the current servicing to be finished. It
-tells the lttvwindow API to call a hook when the actual servicing is over (there
-is a special function for this, as it requires to modify the pool of requests
-actually being serviced : we must make sure that no new reading hooks are
-added!).
-
-
-
-
-
-New Global Attributes
-
-/traces/#
- in LttvTrace attributes :
-
-When a processing is fired, a variable
- computation/modulename/in_progress is set.
-
-When a processing finished, a variable
- computation/modulename/in_progress is unset
- computation/modulename/ready is set
-
-
-
-
-
-Typical Use For a Viewer
-
-When a viewer wants extended information, it must first check if it is ready.
-if not :
-Before a viewer makes a request, it must check the in_progress status of the
-hooks.
-
-If the in_progress is unset, it makes the request.
-
-If the in_progress is set, it makes a special request for being informed of the
-end of request.
-
-
-
-
-Hooks Lists
-
-In order to answer the problems of background processing, we need to add a
-reference counter for each hook of a hook list. If the same hook is added twice,
-it will be called only once, but it will need two "remove" to be really removed
-from the list. Two hooks are identical if they have the same function pointer
-and hook_data.
-
-
-
-
-
-
-Implementation
-
-Ad Hoc Computation
-
-see lttvwindow_events_delivery.txt
-
-
-Hooks Lists
-
-need new ref_count field with each hook
-lttv_hook_add and lttv_hook_add_list must compare addition with present and
-increment ref counter if already present.
-
-lttv_hook_remove and remove_with_data must decrement ref_count is >1, or remove
-the element otherwise (==1).
-
-
-
-Background Scheduler
-
-Global traces
-
-Two global attributes per trace :
-traces/#
- It is a pointer to the LttvTrace structure.
- In the LttvTrace attributes :
- state/
- saved_states/
- statistics/
- modes/
- cpu/
- processes/
- modulename1/
- modulename2/
- ...
- computation/ /* Trace specific background computation hooks status */
- state/
- in_progress
- ready
- stats/
- in_progress
- ready
- modulename1/
- in_progress
- ready
- requests_queue/ /* Background computation requests */
- requests_current/ /* Type : BackgroundRequest */
- notify_queue/
- notify_current/
- computation_traceset/
- computation_traceset_context/
-
-
-computation/ /* Global background computation hooks */
- state/
- before_chunk_traceset
- before_chunk_trace
- before_chunk_tracefile
- after_...
- before_request
- after_request
- event_hook
- event_hook_by_id
- hook_adder
- hook_remover
- stats/
- ...
- modulename1/
- ...
-
-Hook Adder and Hook remover
-
-Hook functions that takes a trace context as call data. They simply
-add / remove the computation related hooks from the trace context.
-
-
-
-Modify Traceset
-Points to the global traces. Main window must open a new one only when no
-instance of the pathname exists.
-
-Modify trace opening / close to make them create and destroy
-LttvBackgroundComputation (and call end requests hooks for servicing requests)
-and global trace info when references to the trace is zero.
-
-
-
-EventsRequest Structure
-
-This structure is the element of the events requests pools. The owner field is
-used as an ownership identifier. The viewer field is a pointer to the data
-structure upon which the action applies. Typically, both will be pointers to
-the viewer's data structure.
-
-In a ad hoc events request, a pointer to the EventsRequest structure is used as
-hook_data in the hook lists : it must have been added by the viewers.
-
-
-Modify module load/unload
-
-A module that registers global computation hooks in the global attributes upon
-load should unregister them when unloaded. Also, it must remove every background
-computation request for each trace that has its own module_name as GQuark.
-
-
-Give an API for calculation modules
-
-Must have an API for module which register calculation hooks. Unregistration
-must also remove all requests made for these hooks.
-
-
-Background Requests Servicing Algorithm (v1)
-
-
-list_in : currently serviced requests
-list_out : queue of requests waiting for processing
-
-notification lists :
-notify_in : currently checked notifications
-notify_out : queue of notifications that comes along with next processing.
-
-
-0.1 Lock traces
-0.2 Sync tracefiles
-
-1. Before processing
- - if list_in is empty
- - Add all requests in list_out to list_in, empty list_out
- - for each request in list_in
- - set hooks'in_progress flag to TRUE
- - call before request hook
- - seek trace to start
- - Move all notifications from notify_out to notify_in.
- - for each request in list_in
- - Call before chunk hooks for list_in
- - add hooks to context *note only one hook of each type added.
-
-2. call process traceset middle for a chunk
- (assert list_in is not empty! : should not even be called in that case)
-
-3. After the chunk
- 3.1 call after_chunk hooks for list_in
- - for each request in list_in
- - Call after chunk hooks for list_in
- - remove hooks from context *note : only one hook of each type
- 3.2 for each notify_in
- - if current time >= notify time, call notify and remove from notify_in
- - if current position >= notify position, call notify and remove from
- notify_in
- 3.3 if end of trace reached
- - for each request in list_in
- - set hooks'in_progress flag to FALSE
- - set hooks'ready flag to TRUE
- - call after request hook
- - remove request
- - for each notifications in notify_in
- - call notify and remove from notify_in
- - reset the context
- - if list_out is empty
- return FALSE (scheduler stopped)
- - else
- return TRUE (scheduler still registered)
- 3.4 else
- - return TRUE (scheduler still registered)
-
-4. Unlock traces
projects / lttv.git / commitdiff
