From: Daniel.Thibault@drdc-rddc.gc.ca (Thibault, Daniel)
Subject: [lttng-dev] Overwrite mode, lost events, and reader behaviour
Date: Mon, 18 Nov 2013 14:43:06 +0000 [thread overview]
Message-ID: <48CF5AC71E61DB46B70D0F388054EFFD267A2924@VAL-E-01.valcartier.drdc-rddc.gc.ca> (raw)
I'd like a clarification. In overwrite mode, and assuming the writers are overwhelming the consumers, what is the behaviour?
Assume we have this situation within a given channel (numbering the sub-buffers in chronological order), and the writers are about to catch up with the reader (the extra sub-buffer is double-bracketed and the sub-buffer it is "shadowing" is marked with a trailing asterisk):
[8] [9] [2] [3] [4] [5] [6] [7] [[-]] reader at [2], writers at [9], spare sub-buffer unused/unallocated
[8] [9] [10]* [3] [4] [5] [6] [7] [[2]] reader at [[2]], writers at [10], spare sub-buffer shadowing [10]
[8] [9] [10]* [11] [4] [5] [6] [7] [[2]] reader at [[2]], writers at [11], spare sub-buffer shadowing [10]
Now, when the reader completes evacuating [[2]], it moves on to [11] and realises there is a time gap. I suspect it does not just jump its clock ahead, because that would give up on [4] through [10]. Does it skip to the next sub-buffer until it sees the clock go backward (the circularity of the buffer guarantees there is always one such discontinuity), resuming its work with [4]? If yes, in the worst case the reader will go once around the sub-buffers, checking timestamps, before resuming its work. This could be avoided if the buffer metadata kept the spare sub-buffer chained to the oldest one (i.e. the third step is [8] [9] [10] [11]* [4] [5] [6] [7] [[2]]), so the reader never needs to call "next()" more than once. Is this what lttng already does?
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/>
next reply other threads:[~2013-11-18 14:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 14:43 Thibault, Daniel [this message]
2013-11-20 14:43 ` Mathieu Desnoyers
2013-11-20 15:38 ` Thibault, Daniel
2013-11-20 15:42 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48CF5AC71E61DB46B70D0F388054EFFD267A2924@VAL-E-01.valcartier.drdc-rddc.gc.ca \
--to=daniel.thibault@drdc-rddc.gc.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox