On 13-09-26 02:13 PM, Thibault, Daniel wrote: > -----Message d'origine----- > De : Julien Desfossez [mailto:[email protected]] > Envoyé : 26 septembre 2013 12:16 > >> When the consumer needs to read a subbuffer, it performs a get_subbuf >> operation. If this operation succeeds, >> the consumer has exclusive access to this subbuffer and so it can read it >> safely. If it fails, it means the tracer is >> currently using it and in the case of snapshots, the consumer will just skip >> to the next one (up to the end >> position it defined at the beginning of the snapshot). >> So if there are gaps for a stream in the recorded snapshot, their size will >> be a multiple of the subbuffer size. >> >> Julien > > Ah, so it occurs at the sub-buffer level. Simple and efficient. > > Is the following scenario possible? The consumer tries to get_subbuf, and > is denied access (because tracers are writing into it). It then tries to get > the next sub-buffer, but the luck of task scheduling is such that by the time > it actually calls the request routine, the tracers have already overwritten > the sub-buffer in question and gone on to the next one. The get_subbuf > succeeds and the consumer keeps doing its thing (the timestamps remain > monotonically increasing, so there is no corruption). The resulting snapshot > on disk has a large jump in its timestamps, having lost a whole buffer > cycle's worth of event records. > > To complicate things, the tracers then stop (for lack of event > occurrences) in some sub-buffer ahead of the consumer's current position, but > still short of the consumer's stop goal. When the consumer skips over the > busy sub-buffer (where the tracers are "stuck"), it would read events that > apparently jump back in time (a whole buffer cycle's worth of time), so I > guess it would stop there and close the snapshot?
One important design note to understand this situation : even though we write in a ring-buffer, the positions are free-running counters, they "never" wrap-around (well, we are dealing with 64-bit counters). In order to map a position to an actual subbuffer, we use a sort of modulo. This operation gives us the actual subbuffer to use and also allows us to detect if the tracer has already reused this subbuffer. > > On a somewhat related topic, how does the session daemon handle the > context added to a channel? Is it a set of instructions (flags, really) sent > to the tracer, similar to filter pseudo-code (but much less complicated)? The contexts are kind of "hooks" activated at the channel level that are activated when an event is recorded. It is not code sent by the session daemon to the tracer (unlike filters), the code to fetch the information is already in the tracer. So it is basically the same kind of operation as activating an event in a channel. Julien > > Daniel U. Thibault > Protection des systèmes et contremesures (PSC) | Systems Protection & > Countermeasures (SPC) > Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber > Security (MCCS) > R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D > Canada - Valcartier (DRDC Valcartier) > 2459 route de la Bravoure > Québec QC G3J 1X5 > CANADA > Vox : (418) 844-4000 x4245 > Fax : (418) 844-4538 > NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ> > Gouvernement du Canada | Government of Canada > <http://www.valcartier.drdc-rddc.gc.ca/> > > _______________________________________________ > lttng-dev mailing list > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
