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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.