-----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? 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)? 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
