Re: [lttng-dev] [RFC PATCH] Introduce timekeeper latch synchronization

2013-09-13 Thread Peter Zijlstra
On Thu, Sep 12, 2013 at 10:52:53PM -0400, Mathieu Desnoyers wrote: OK! Here is the full implementation of the idea against Linux timekeeper, ntp, and PPS. It appears that ntp and PPS were relying on the timekeeper seqlock too. And guess what, after booting my laptop with this kernel there

Re: [lttng-dev] Running lttng-tools testsuite against an installed codebase

2013-09-13 Thread Stefan Seefeld
On 09/12/2013 06:29 PM, Christian Babeux wrote: Hi lttng-testers, The current lttng-tools testsuite has some limitations as recently pointed out on this OpenEmbedded thread [1]. The testsuite cannot be runned against an installed codebase of lttng-tools because the tests assume that the

Re: [lttng-dev] [RFC PATCH] Introduce timekeeper latch synchronization

2013-09-13 Thread Mathieu Desnoyers
* Mathieu Desnoyers (mathieu.desnoy...@efficios.com) wrote: [...] @@ -1362,29 +1398,31 @@ static inline void old_vsyscall_fixup(struct timekeeper *tk) static void update_wall_time(void) { [...] - /* - * Update the real timekeeper. - * - * We could avoid this memcpy by

Re: [lttng-dev] [RFC PATCH] Introduce timekeeper latch synchronization

2013-09-13 Thread Thomas Gleixner
On Thu, 12 Sep 2013, Mathieu Desnoyers wrote: * Peter Zijlstra (pet...@infradead.org) wrote: [...] Yep, that's good. I suppose if there's multiple use sites we can jump through another few hoops to get rid of the specific struct foo assumptions by storing sizeof() whatever we do use and

Re: [lttng-dev] [RFC PATCH] Introduce timekeeper latch synchronization

2013-09-13 Thread John Stultz
On 09/13/2013 10:05 AM, Mathieu Desnoyers wrote: On 13/09/13 09:13 AM, Thomas Gleixner wrote: On Thu, 12 Sep 2013, Mathieu Desnoyers wrote: * Peter Zijlstra (pet...@infradead.org) wrote: [...] Yep, that's good. I suppose if there's multiple use sites we can jump through another few hoops to

Re: [lttng-dev] [RFC PATCH] Introduce timekeeper latch synchronization

2013-09-13 Thread Mathieu Desnoyers
On 13/09/13 09:13 AM, Thomas Gleixner wrote: On Thu, 12 Sep 2013, Mathieu Desnoyers wrote: * Peter Zijlstra (pet...@infradead.org) wrote: [...] Yep, that's good. I suppose if there's multiple use sites we can jump through another few hoops to get rid of the specific struct foo assumptions by

Re: [lttng-dev] [RFC PATCH] Introduce timekeeper latch synchronization

2013-09-13 Thread Mathieu Desnoyers
* John Stultz (john.stu...@linaro.org) wrote: On 09/13/2013 10:05 AM, Mathieu Desnoyers wrote: On 13/09/13 09:13 AM, Thomas Gleixner wrote: On Thu, 12 Sep 2013, Mathieu Desnoyers wrote: * Peter Zijlstra (pet...@infradead.org) wrote: [...] Yep, that's good. I suppose if there's multiple

Re: [lttng-dev] [RFC PATCH] Introduce timekeeper latch synchronization

2013-09-13 Thread John Stultz
On 09/13/2013 11:20 AM, Mathieu Desnoyers wrote: This looks to me like interesting optimisation work that should be considered after the following question is answered: does the added update-side cost actually matter that much ? Yea, fair enough. We can measure the cost first. thanks -john

Re: [lttng-dev] [RFC PATCH] Introduce timekeeper latch synchronization

2013-09-13 Thread John Stultz
On 09/13/2013 08:30 AM, Mathieu Desnoyers wrote: By the way, if there are some standard test-bench for timekeeping, I'd be very interested to hear about them. I've got a git repo of tests that I use for basic sanity checks here: https://github.com/johnstultz-work/timetests.git thanks -john

Re: [lttng-dev] Running lttng-tools testsuite against an installed codebase

2013-09-13 Thread Christian Babeux
Of course, that would break the `make check` target as for in-development testing the binaries would no longer be found. Is there any reason a simple adjustment of the PATH variable would not be enough ? One of the issue I see with overriding the PATH _only_ in the make check target is that

Re: [lttng-dev] Running lttng-tools testsuite against an installed codebase

2013-09-13 Thread Stefan Seefeld
On 09/13/2013 03:56 PM, Christian Babeux wrote: Of course, that would break the `make check` target as for in-development testing the binaries would no longer be found. Is there any reason a simple adjustment of the PATH variable would not be enough ? One of the issue I see with overriding

[lttng-dev] [PATCH] Declare enum type to use from C++

2013-09-13 Thread Francis Giraldeau
Anonymous enum can't be referenced from C++. to fix this issue, declare enum bt_iter_pos_type and use this type in struct bt_iter_pos. Signed-off-by: Francis Giraldeau francis.girald...@gmail.com --- include/babeltrace/iterator.h | 16 +--- 1 file changed, 9 insertions(+), 7

Re: [lttng-dev] [PATCH lttng-tools] Enable support for installcheck

2013-09-13 Thread David Goulet
Merged thanks! David Stefan Seefeld: 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

Re: [lttng-dev] [PATCH] Declare enum type to use from C++

2013-09-13 Thread Mathieu Desnoyers
merged, thanks! * Francis Giraldeau (francis.girald...@gmail.com) wrote: Anonymous enum can't be referenced from C++. to fix this issue, declare enum bt_iter_pos_type and use this type in struct bt_iter_pos. Signed-off-by: Francis Giraldeau francis.girald...@gmail.com ---

Re: [lttng-dev] [RFC PATCH] Introduce timekeeper latch synchronization

2013-09-13 Thread Mathieu Desnoyers
* John Stultz (john.stu...@linaro.org) wrote: On 09/13/2013 08:30 AM, Mathieu Desnoyers wrote: By the way, if there are some standard test-bench for timekeeping, I'd be very interested to hear about them. I've got a git repo of tests that I use for basic sanity checks here: