LTTng 0.6.5
Mathieu Desnoyers <[email protected]>
| Newsgroups | gmane.linux.kernel.tracing |
|---|---|
| Message-ID | <20061010130209.GA6200@Krystal> |
Hi, The following git diff : http://ltt.polymtl.ca/cgi-bin/gitweb.cgi?p=linux-2.6-lttng.git;a=commit;h=f38db9e6429337c51263eb793dafe666b673eac1 introduces a change in the LTTng reserve/commit algorithm. The goal is to simplify the algorithm by removing the unnecessary "reserve count". The previous versions kept the reserve count unincremented until the end of subbuffer is reached. When it happened, it incremented the reserve count by the number of bytes written in the subbuffer. Now, I removed this variable. Instead, I increment the commit count by the number of bytes of padding at the end of the subbuffer. The condition that had to be met previously by a subbuffer (commit count == reserve count) so it would be considered readable and uncorrupted is now (commit count % subbuffer size) == 0 Doing this will let me do some very nice things in the next versions, like implementing "read" of partially written subbuffers. The supplementary information I can now use is : If the write offset is within the same subbuffer as the consumer offset, if commit_count%subbuffer size == write offset%subbuffer size, then we can read all the bytes from the beginning of the subbuffer up to commit_count%subbuffer size, because we know they are ordered. It will also be useful for traces taken upon a crash. Comments and review are welcome. Mathieu OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68