I agree with Paul, that no redundant data gets replicated with his
approach, and my only concern is that this approach really forces a viewer
to be sequential.
Maybe forces is too strong a word - but a viewer than wants to let you
roam the trace freely will have to read the entire trace to
I guess that you are mostly interested in making sure your traces are
readable after a crash from the system that produces them, right ?
That is a concern, yes.
Additionally, I would like to make sure that I can safely view events on a
running system up to (close to) the end. Plus - I rather
Hi Daniel,
I can see your point about how the events are created. I do not completely
agree with your views, but it is not essential that I do.
How about the following (this is based on the ideas you have brought forth):
We keep the enable-event command as it is. However, we enhance the event
We keep the enable-event command as it is. However, we enhance the event name
specification syntax somewhat. We could of course do a full regex matching,
but I
fear that would get too slow. Instead we'd have something like
$ lttng enable-event -u *!mine*!alsomine
This would enable any
This kind of a solution is viable.
Here are the concerns we still need to hammer out for this -
Seeking to an arbitrary time means that our events (P frames by analogy)
need to point to the full shared object state dump (the I-frame) somehow.
In video compression, the decoder (trace viewer in
Starting from commit 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40
timekeeping: Hold timekeepering locks in do_adjtimex and hardpps
(3.10 kernels), the xtime write seqlock is held across calls to
__do_adjtimex(), which includes a call to notify_cmos_timer(), and hence
schedule_delayed_work().
This
Fix an issue affecting lttng-modules with Linux kernels starting with
3.10.
This patch depends on Linux kernel patch:
timekeeping: introduce timekeeping_is_busy()
Starting from Linux kernel commit
06c017fdd4dc48451a29ac37fc1db4a3f86b7f40 timekeeping: Hold
timekeepering locks in do_adjtimex and
Hi everyone,
Here is the network protocol RFC for the JUL support in lttng-tools. It covers
only the communication between the Java LTTng Agent and the session daemon.
A second RFC will follow this week for the new JUL domain ABI/API in
lttng-tools.
NOTE: There is still a black spot in that
Oh that makes me think!
We should apply to get 5342 and 5343 in /etc/services as well :)
Cheers!
David
Philippe Proulx:
Hi guys.
It's been a while, but just to let you know that recognition for CTF
channel files and packetized/text metadata files by file(1) is now
pushed upstream
On Wed, 11 Sep 2013 09:40:51 -0700
John Stultz john.stu...@linaro.org wrote:
(and it avoids me forgetting to set the owner in some future change,
further mucking things up :).
Wow, I had to read that twice to see what you really wrote. I was
thinking damn, John is getting vulgar! ;-)
-- Steve
On 09/11/2013 08:12 AM, Mathieu Desnoyers wrote:
LTTng uses ktime to have the same time-base across kernel and
user-space, so traces gathered from LTTng-modules and LTTng-UST can be
correlated. We plan on using ktime until a fast, scalable, and
fine-grained time-source for tracing that can be
On 09/11/2013 08:08 AM, Mathieu Desnoyers wrote:
Starting from commit 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40
timekeeping: Hold timekeepering locks in do_adjtimex and hardpps
(3.10 kernels), the xtime write seqlock is held across calls to
__do_adjtimex(), which includes a call to
Hi John,
* John Stultz (john.stu...@linaro.org) wrote:
On 09/11/2013 08:08 AM, Mathieu Desnoyers wrote:
Starting from commit 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40
timekeeping: Hold timekeepering locks in do_adjtimex and hardpps
(3.10 kernels), the xtime write seqlock is held across
On 09/11/2013 10:49 AM, Mathieu Desnoyers wrote:
Hi John,
* John Stultz (john.stu...@linaro.org) wrote:
On 09/11/2013 08:08 AM, Mathieu Desnoyers wrote:
Starting from commit 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40
timekeeping: Hold timekeepering locks in do_adjtimex and hardpps
(3.10
* John Stultz (john.stu...@linaro.org) wrote:
On 09/11/2013 08:12 AM, Mathieu Desnoyers wrote:
LTTng uses ktime to have the same time-base across kernel and
user-space, so traces gathered from LTTng-modules and LTTng-UST can be
correlated. We plan on using ktime until a fast, scalable, and
* John Stultz (john.stu...@linaro.org) wrote:
On 09/11/2013 08:08 AM, Mathieu Desnoyers wrote:
[...]
Now focusing on features (the fix discussion is in a separate
sub-thread):
LTTng uses ktime to have the same time-base across kernel and
user-space, so traces gathered from LTTng-modules
On Wed, Sep 11, 2013 at 02:54:41PM -0400, Mathieu Desnoyers wrote:
* John Stultz (john.stu...@linaro.org) wrote:
On 09/11/2013 08:08 AM, Mathieu Desnoyers wrote:
[...]
Now focusing on features (the fix discussion is in a separate
sub-thread):
LTTng uses ktime to have the same
Enable execution of tests via `make installcheck`, i.e. against a fully
installed
LTTng.
The patch simply adds the same rule to the installcheck target that is used for
check.
Testing with an OpenEmbedded build shows the unit_tests suite to work fine,
while
the fast_regression suite contains
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
On Wed, Sep 11, 2013 at 02:54:41PM -0400, Mathieu Desnoyers wrote:
[...]
If we can afford a synchronize_rcu_sched() wherever the write seqlock is
needed, we could go with the following. Please note that I use
synchronize_rcu_sched()
On Wed, Sep 11, 2013 at 08:48:11PM -0400, Mathieu Desnoyers wrote:
Thoughts ?
struct foo {
...
};
spinlock_t foo_lock;
unsigned int foo_head = 0;
unsigned int foo_tail = 0;
struct foo foo_array[2];
void foo_assign(struct foo f)
{
spin_lock(foo_lock);
foo_head++;
* Peter Zijlstra (pet...@infradead.org) wrote:
On Wed, Sep 11, 2013 at 08:48:11PM -0400, Mathieu Desnoyers wrote:
Thoughts ?
struct foo {
...
};
spinlock_t foo_lock;
unsigned int foo_head = 0;
unsigned int foo_tail = 0;
struct foo foo_array[2];
void foo_assign(struct foo
21 matches
Mail list logo
