G */
>> "4: \n\t "
>> "jmp % l[aborted] \n\t "
>> : /* no outputs */
>> : [cpu_id] "r" (cpu),
>> [current_cpu_id] "m" ( __rseq_abi . cpu_id ),
>> [rseq_cs] "m" ( __rseq_abi . rseq_cs )
>> : "memory" , &quo
_pid_tracker ust 0 "${EVENT_NAME}"
> - test_event_pid_track_untrack ust 0 "${EVENT_NAME}"
The approach looks good to me, thanks!
Acked-by: Mathieu Desnoyers
>
> Signed-off-by: Anders Wallin
> ---
> .../tools/tracker/test_event_tracker | 18 +-
> 1 file change
uot; or in "utils.sh"
Actually, this helper already exists in utils.sh:
validate_trace_session_ust_empty (), which
internally uses validate_directory_empty (). As you point out, we should use
validate_trace_session_ust_empty for the validation of those test cases which
populate no
trace whatsoever.
ion stopped."
> - rm "$BEFORE_LAST_PATH"
> - rm "$AFTER_FIRST_PATH"
> + rm "$BEFORE_FIRST_PATH"
> }
>
> function prepare_kernel_app
> --
> 2.31.1
>
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
}
> @@ -175,22 +238,28 @@ int main(int argc, char **argv)
> }
>
> if (before_exit_file_path_touch) {
> + TRACE("before_exit_file_path_touch(%i): %s\n",
> + i, before_exit_file_path_touch);
> ret = create_file(bef
stretched on time
here, so maybe they will have time to answer before I do.
Meanwhile, if you could provide details about your architecture, kernel
.config, and a
small reproducer program, it would help bootstrapping the discussion.
Thanks,
Mathieu
> Best,
> Mingyi
--
Mat
ad exit, and unregister qsbr that way,
Hoping this help!
Best regards,
Mathieu
>
> Jeff
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyer
CI workers.
>
> We need to add proper rendez-vous based synchronization to the test if some
> is missing.
>
> Adding Jérémie in CC.
And then I read on the rest of the email thread... so it's being taken care of,
good! :)
Thanks,
Mathieu
>
> Thanks,
>
> Mathieu
>
>
>> }
>>
>> functi
ons on the CI workers.
We need to add proper rendez-vous based synchronization to the test if some
is missing.
Adding Jérémie in CC.
Thanks,
Mathieu
> }
>
> function trace_ust_app
> --
> 2.31.1
>
> ___
> lttng-dev mailing list
> l
- On Mar 11, 2021, at 11:51 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Thu, Mar 11, 2021 at 09:51:56AM -0500, Mathieu Desnoyers wrote:
>>
>>
>> - On Feb 26, 2021, at 8:51 AM, Piotr Figiel fig...@google.com wrote:
>>
>> > For userspac
ddress and the signature value
> with the new ptrace request PTRACE_GET_RSEQ_CONFIGURATION.
>
> This new ptrace request can also be used by debuggers so they are aware
> of stops within restartable sequences in progress.
>
> Signed-off-by: Piotr Figiel
> Reviewed-by: Michal Miroslaw
Reviewed-by
The following commit has been merged into the sched/core branch of tip:
Commit-ID: ce29ddc47b91f97e7f69a0fb7cbb5845f52a9825
Gitweb:
https://git.kernel.org/tip/ce29ddc47b91f97e7f69a0fb7cbb5845f52a9825
Author:Mathieu Desnoyers
AuthorDate:Wed, 17 Feb 2021 11:56:51 -05:00
- On Feb 26, 2021, at 9:11 AM, Piotr Figiel fig...@google.com wrote:
> Hi,
>
> On Mon, Feb 22, 2021 at 09:53:17AM -0500, Mathieu Desnoyers wrote:
>
>> I notice that other structures defined in this UAPI header are not
>> packed as well. Should we add an attribute
- On Feb 26, 2021, at 11:06 AM, Piotr Figiel fig...@google.com wrote:
> Hi,
>
> On Fri, Feb 26, 2021 at 10:32:35AM -0500, Mathieu Desnoyers wrote:
>> > +static long ptrace_get_rseq_configuration(struct task_struct *task,
>> > +
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: fba111913e51a934eaad85734254eab801343836
Gitweb:
https://git.kernel.org/tip/fba111913e51a934eaad85734254eab801343836
Author:Mathieu Desnoyers
AuthorDate:Wed, 17 Feb 2021 11:56:51 -05:00
- On Feb 26, 2021, at 11:04 AM, emmir em...@google.com wrote:
> On Fri, 26 Feb 2021 at 16:32, Mathieu Desnoyers
> wrote:
>>
>> - On Feb 26, 2021, at 8:51 AM, Piotr Figiel fig...@google.com wrote:
>> [...]
>> > ---
>> > v2:
>> > Applie
__u32 pad;
};
where:
.size = sizeof(struct ptrace_rseq_configuration),
This way, the configuration structure can be expanded in the future. The
rseq ABI structure is by definition fixed-size, so there is no point in
having its size here.
Florian, did I understand your request correctly, or am I missing your point ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Feb 24, 2021, at 1:14 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 24 Feb 2021 11:59:35 -0500 (EST)
> Mathieu Desnoyers wrote:
>>
>> As a prototype solution, what I've done currently is to copy the user-space
>> data into a kmalloc'd buffer in a preparati
rs (for IPIed readers) and by
> +// scheduler context-switch ordering (for locked-down non-running readers).
The rest looks good, thanks!
Mathieu
>
> // The lockdep state must be outside of #ifdef to be useful.
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Feb 25, 2021, at 10:36 AM, paulmck paul...@kernel.org wrote:
> On Thu, Feb 25, 2021 at 09:22:48AM -0500, Mathieu Desnoyers wrote:
>> Hi Paul,
>>
>> Answering a question from Peter on IRC got me to look at
>> rcu_read_lock_trace(),
>> and I se
prevent
progress of the grace period.
Without this, a steady flow of incoming tasks-trace-RCU readers can prevent the
grace period from ever completing.
Or is this handled in a clever way that I am missing here ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- Mathieu Desnoyers wrote:
> - On Feb 24, 2021, at 11:22 AM, Michael Jeanson mjean...@efficios.com
> wrote:
>
> > [ Adding Mathieu Desnoyers in CC ]
> >
> > On 2021-02-23 21 h 16, Steven Rostedt wrote:
> >> On Thu, 18 Feb 2021 17:21:
- On Feb 24, 2021, at 11:22 AM, Michael Jeanson mjean...@efficios.com wrote:
> [ Adding Mathieu Desnoyers in CC ]
>
> On 2021-02-23 21 h 16, Steven Rostedt wrote:
>> On Thu, 18 Feb 2021 17:21:19 -0500
>> Michael Jeanson wrote:
>>
>>> This s
,
> + .signature = task->rseq_sig,
> + };
> +
> + size = min_t(unsigned long, size, sizeof(conf));
> + if (copy_to_user(data, , size))
> + return -EFAULT;
> + return size;
See other email about returning 0 here.
Thanks,
Mathieu
> +
> default:
> break;
> }
> --
> 2.30.0.617.g56c4b15f3c-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ts would be to return 0 when
everything
is OK. Unless there a strong motivation for doing different for this new
request, I
would be tempted to use the same expected behavior than other requests on
success:
return 0.
Unless there is a strong motivation for returning either size or sizeof(conf) ?
If we
return sizeof(conf) to user-space, it means it should check it and deal with the
size mismatch. Is that size ever expected to change ?
Thanks,
Mathieu
>
>
> --
> ldv
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
be enabled by default as well. Or if some new options should enable "typical"
usage scenarios.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
be enabled by default as well. Or if some new options should enable "typical"
usage scenarios.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng
- On Feb 17, 2021, at 8:41 PM, Tomasz Kłoczko kloczko.tom...@gmail.com
wrote:
> Hi,
> Just tested 0.12.2 and look s like build fails on compile test programs:
Hi,
Adding Michael and the lttng-dev mailing list in CC.
Can you provide information about your build environment ? Which
ior to version 5.1, because they perform
unsafe access
to deallocated stack.
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ior to version 5.1, because they perform
unsafe access
to deallocated stack.
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.
g.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
between rcu_barrier() and call_rcu_data_free()
Project website: http://liburcu.org
Git repository: git://git.liburcu.org/urcu.git
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
between rcu_barrier() and call_rcu_data_free()
Project website: http://liburcu.org
Git repository: git://git.liburcu.org/urcu.git
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https
to on_each_cpu_mask().
Fixes: 227a4aadc75b ("sched/membarrier: Fix p->mm->membarrier_state racy load")
Link: https://lore.kernel.org/r/74f1e842-4a84-47bf-b6c2-5407dfdd4...@gmail.com
Signed-off-by: Mathieu Desnoyers
Reported-by: Nadav Amit
Cc: Peter Zijlstra
Cc: Nadav Amit
Cc: sta...@vger.ke
d/membarrier: Fix p->mm->membarrier_state racy load")
> Is that the intention of the code?
Clearly not! If we look at sync_runqueues_membarrier_state(), there is even a
special-case for mm_users==1 || num online cpus == 1 where it writes the
membarrier
state into the current cpu runqueu
- On Oct 28, 2020, at 5:23 PM, Alexei Starovoitov
alexei.starovoi...@gmail.com wrote:
> On Tue, Oct 27, 2020 at 09:37:08AM -0400, Mathieu Desnoyers wrote:
>>
>> - On Oct 26, 2020, at 6:43 PM, Alexei Starovoitov
>> alexei.starovoi...@gmail.com wrote:
>>
>
- On Feb 10, 2021, at 12:09 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
> On Wed, Feb 10, 2021 at 11:04:19AM -0500, Mathieu Desnoyers wrote:
>> Hi,
>>
>> While reconciling the lttng-modules writeback instrumentation with its
>> counterpart
>> wi
68f23b89067fdf187763e75a56087550624fdbee
("memcg: fix a crash in wb_workfn when a device disappears")
Considering that this fix was CC'd to the stable mailing list, is there any
reason why it has not been integrated into those LTS branches ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS
least version enum labels or
> somesuch?
>
> /Jesper
>
> ________
> Från: lttng-dev för Mathieu Desnoyers via
> lttng-dev
> Skickat: den 26 januari 2021 16:19
> Till: lttng-dev
> Ämne: [lttng-dev] Community input: Feedback on use of enu
- On Feb 8, 2021, at 3:09 PM, rostedt rost...@goodmis.org wrote:
> Broke this up into two patches now. See the second patch for the
> description of waht this series is doing.
For both patches:
Reviewed-by: Mathieu Desnoyers
>
> Changes since v2:
>
> Added a patch to
n.
Thanks,
Mathieu
> Thanks, we appreciate the help beforehand!
> Mohammad
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
- On Feb 5, 2021, at 10:40 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Fri, Feb 05, 2021 at 10:09:26AM -0500, Mathieu Desnoyers wrote:
>> Then we should be able to generate the following using static keys as a
>> jump table and N static calls:
>>
>> j
stack setup
call
label_N-1:
stack setup
call
label_N-2:
stack setup
call
...
label_0:
jump end
label_fallback:
end:
So the static keys would be used to jump to the appropriate label (using
a static branch, which has pretty much 0 overhead). Static calls would
be used to implement each of the calls.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
me)(args);\
> - } \
> + __DO_TRACE_CALL(name, TP_ARGS(args)); \
> \
> if (rcuidle) { \
> rcu_irq_exit_irqson(); \
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ep his signature, but I will take the responsibility of this
> being correct, and keep the authorship.
>
> Signed-off-by: Mathieu Desnoyers
> Signed-off-by: Steven Rostedt (VMware)
> ---
> include/linux/tracepoint.h | 2 +-
> kernel/tracepoint.c| 92 +++
This patch is only compile-tested.
Signed-off-by: Mathieu Desnoyers
---
include/linux/tracepoint.h | 2 +-
kernel/tracepoint.c| 80 +-
2 files changed, 28 insertions(+), 54 deletions(-)
diff --git a/include/linux/tracepoint.h b/include/linux
icks and is more complex, but
> can be an alternative if this solution becomes an issue.
>
> Link:
> https://lore.kernel.org/lkml/20210127170721.58bce...@gandalf.local.home/
> ]
>
> Cc: Peter Zijlstra
> Cc: Josh Poimboeuf
> Cc: Mathieu Desnoyers
> Cc: Ingo Mo
- On Jan 27, 2021, at 2:16 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 27 Jan 2021 13:13:22 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> > Thanks for bringing that up.
>>
>> Requiring an RCU synchronize on element removal is quite intrusive, and can
&
- On Jan 27, 2021, at 1:07 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 27 Jan 2021 13:00:46 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> > Instead of allocating a new array for removing a tracepoint, allocate twice
>> > the needed size when adding tracepoint
>
> static void tracepoint_update_call(struct tracepoint *tp, struct
> tracepoint_func
> *tp_funcs, bool sync)
> @@ -309,8 +339,8 @@ static int tracepoint_remove_func(struct tracepoint *tp,
> rcu_assign_pointer(tp->funcs, tp_funcs);
> } else {
> rcu_assign_pointer(tp->funcs, tp_funcs);
> - tracepoint_update_call(tp, tp_funcs,
> -tp_funcs[0].func != old[0].func);
> + /* Need to sync, if going back to a single caller */
> + tracepoint_update_call(tp, tp_funcs, tp_funcs[1].func == NULL);
> }
> release_probes(old);
> return 0;
> --
> 2.25.4
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
d is stopped/frozen while the read is done.
Maybe we should consider validating that the proc file is used from the right
context
(from self or when the target thread is stopped/frozen) rather than add dubious
locking ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
-tracepoint-enum
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
gt;
> [Please note this e-mail is from an EXTERNAL e-mail address]
>
>>Hi Quiang,
>>
>>Please test the attached patch.
>
> Hello Jonathan
>
> Thank you for your patch, I can compile successfully after testing.
Patch pushed into lttng-modules master, tha
proc_tgid_stat),
> @@ -3522,6 +3540,9 @@ static const struct pid_entry tid_base_stuff[] = {
>_pid_set_comm_operations, {}),
> #ifdef CONFIG_HAVE_ARCH_TRACEHOOK
> ONE("syscall", S_IRUSR, proc_pid_syscall),
> +#ifdef CONFIG_RSEQ
> + ONE("rseq", S_IRUSR, proc_pid_rseq),
> +#endif
> #endif
> REG("cmdline", S_IRUGO, proc_pid_cmdline_ops),
> ONE("stat", S_IRUGO, proc_tid_stat),
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
; Thanks a lot.
> Btw, have a nice holiday!
> Serica
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_
the core executing this call is not allowed to block, but the
> other part indicates that the other CPUs _have_ executed a serialising
> instruction before this call returns... one wonders how that happens
> without blocking. Maybe the CPU spins waiting for completion instead?
Membarrier expedited sync-core issues IPIs to all CPUs running sibling
threads. AFAIR the IPI mechanism uses the "csd lock" which is basically
busy waiting. So it does not "block", it busy-waits.
For completeness of the explanation, other (non-running) threads acting
on the same mm will eventually issue the context synchronizing instruction
before returning to user-space whenever they are scheduled back.
Thanks,
Mathieu
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_icache_user_range on arm32.
So between code modification and allowing other threads to jump to that code,
it should be expected that architectures without coherent i/d cache will need
to flush caches to ensure coherency *and* to issue membarrier to make sure
core serializing instructions will be issued by every thread acting on the
same mm either immediately by means of the IPI, or before they return to
user-space if they do not happen to be currently running when the membarrier
system call is invoked.
Hoping this clarifies things. I suspect we will need to clarify documentation
about what membarrier *does not* guarantee, given that you mistakenly expected
membarrier to take care of cache flushing.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Dec 28, 2020, at 4:06 PM, Andy Lutomirski l...@kernel.org wrote:
> On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On Mon, Dec 28, 2020 at 11:09
ring/Barriers/ISB-in-more-detail
[2]
https://montcs.bloomu.edu/Information/ARMv8/ARMv8-A_Architecture_Reference_Manual_(Issue_A.a).pdf
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Dec 28, 2020, at 4:06 PM, Andy Lutomirski l...@kernel.org wrote:
> On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On Mon, Dec 28, 2020 at 11:09
ring/Barriers/ISB-in-more-detail
[2]
https://montcs.bloomu.edu/Information/ARMv8/ARMv8-A_Architecture_Reference_Manual_(Issue_A.a).pdf
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
the core executing this call is not allowed to block, but the
> other part indicates that the other CPUs _have_ executed a serialising
> instruction before this call returns... one wonders how that happens
> without blocking. Maybe the CPU spins waiting for completion instead?
Membarrier expedited sync-core issues IPIs to all CPUs running sibling
threads. AFAIR the IPI mechanism uses the "csd lock" which is basically
busy waiting. So it does not "block", it busy-waits.
For completeness of the explanation, other (non-running) threads acting
on the same mm will eventually issue the context synchronizing instruction
before returning to user-space whenever they are scheduled back.
Thanks,
Mathieu
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_icache_user_range on arm32.
So between code modification and allowing other threads to jump to that code,
it should be expected that architectures without coherent i/d cache will need
to flush caches to ensure coherency *and* to issue membarrier to make sure
core serializing instructions will be issued by every thread acting on the
same mm either immediately by means of the IPI, or before they return to
user-space if they do not happen to be currently running when the membarrier
system call is invoked.
Hoping this clarifies things. I suspect we will need to clarify documentation
about what membarrier *does not* guarantee, given that you mistakenly expected
membarrier to take care of cache flushing.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
use of `eret` on aarch64 guarantees a context
synchronizing
instruction when returning to user-space.
Thanks,
Mathieu
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: Nicholas Piggin
> Cc: Catalin
use of `eret` on aarch64 guarantees a context
synchronizing
instruction when returning to user-space.
Thanks,
Mathieu
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Nicholas Piggin
> Cc: Catalin
; lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
-O1"
> -])
> -
> # Search for clock_gettime
> AC_SEARCH_LIBS([clock_gettime], [rt], [
> AC_DEFINE([CONFIG_RCU_HAVE_CLOCK_GETTIME], [1])
> --
> 2.29.2
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
ARM_HAVE_DMB */
> +
> +#endif /* URCU_ARCH_ARMV7 */
>
> #include
> #include
> diff --git a/include/urcu/config.h.in b/include/urcu/config.h.in
> index faf7817..99d763a 100644
> --- a/include/urcu/config.h.in
> +++ b/include/urcu/config.h.in
> @@ -5,9 +5,6 @@
>behavior of SMP systems is undefined. */
> #undef CONFIG_RCU_SMP
>
> -/* Use the dmb instruction is available for use on ARM. */
> -#undef CONFIG_RCU_ARM_HAVE_DMB
> -
> /* TLS provided by the compiler. */
> #undef CONFIG_RCU_TLS
>
> --
> 2.29.2
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
RSION >= 40400 && URCU_GCC_VERSION <= 40402
> +# error Your gcc version has a non-functional __sync_synchronize()
> +# endif
> +#endif
> +
> #ifdef __cplusplus
> }
> #endif
> --
> 2.29.2
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_
__ * 1 \
> + __GNUC_MINOR__ * 100 \
> + __GNUC_PATCHLEVEL__)
> -
> -/*
> - * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
> - */
> -# ifdef __ARMEL__
> -# if URCU_GCC_VERSION >= 40800 && URCU_GCC
?
Thanks,
Mathieu
- On Dec 9, 2020, at 1:29 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Hi Paul,
>
> Should I merge this temporary fix for liburcu tests, or should we go
> for dynamic allocation of the array right away instead ?
>
> Thanks,
>
> Mat
-108,7 +108,7 @@ static void spin_unlock(spinlock_t *sp)
>
> typedef pthread_t thread_id_t;
>
> -#define NR_THREADS 128
> +#define NR_THREADS 256
>
> #define __THREAD_ID_MAP_EMPTY ((thread_id_t) 0)
> #define __THREAD_ID_MAP_WAITING ((thread_id_t) 1)
for?
>> +membarrier_mm_sync_core_before_usermode(next);
>
> On the other hand the reason for this mm check that you mention contradicts
> my previous understanding as the git log says:
>
> commit 2840cf02fae627860156737e83326df354ee4ec6
> Author: Math
for?
>> +membarrier_mm_sync_core_before_usermode(next);
>
> On the other hand the reason for this mm check that you mention contradicts
> my previous understanding as the git log says:
>
> commit 2840cf02fae627860156737e83326df354ee4ec6
> Author: Math
known by the scheduler to sync core, and it appears it may be
a bit more heavy that what is strictly needed.
Your change instead rely on the internal knowledge of lazy TLB within x86
switch_mm_irqs_off to achieve this, which overall seems like an improvement.
I agree with Nick's comment that it should go on top of his exit_lazy_mm
patches.
Thanks,
Mathieu
> + if (mm)
> mmdrop(mm);
> - }
> +
> if (unlikely(prev_state == TASK_DEAD)) {
> if (prev->sched_class->task_dead)
> prev->sched_class->task_dead(prev);
> --
> 2.28.0
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
known by the scheduler to sync core, and it appears it may be
a bit more heavy that what is strictly needed.
Your change instead rely on the internal knowledge of lazy TLB within x86
switch_mm_irqs_off to achieve this, which overall seems like an improvement.
I agree with Nick's comment that it should go on top of his exit_lazy_mm
patches.
Thanks,
Mathieu
> + if (mm)
> mmdrop(mm);
> - }
> +
> if (unlikely(prev_state == TASK_DEAD)) {
> if (prev->sched_class->task_dead)
> prev->sched_class->task_dead(prev);
> --
> 2.28.0
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
gt;
> As an optimization, this avoids an extra smp_mb() in the default
> barrier-only mode.
^ we could also add to the commit message that it avoids doing rseq preempt
on the caller as well.
Other than that:
Reviewed-by: Mathieu Desnoyers
Thanks!
Mathieu
>
> Cc: sta...@vger
surprised that the core membarrier code doesn't currently show up in a
> such a search.)
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andy Lutomirski
Reviewed-by: Mathieu Desnoyers
> ---
> kernel/sched/membarrier.c | 18 ++
> 1 file changed, 18 insertions(+
ice, nothing actually guarantees it by a strict reading of the
> x86 manuals. Rather than providing this guarantee by accident and
> potentially causing a problem down the road, just add an explicit
> barrier.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andy Lutomirski
ections. The kernel even
kills
the offending applications when run on kernels with CONFIG_DEBUG_RSEQ=y. So it
seems
rather pointless to waste cycles doing a rseq fence on self considering this.
Thanks,
Mathieu
> + */
> + if (ipi_func == ipi_mb) {
> + p
- On Dec 1, 2020, at 1:48 PM, Andy Lutomirski l...@kernel.org wrote:
> On Tue, Dec 1, 2020 at 10:29 AM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 1, 2020, at 1:12 PM, Andy Lutomirski l...@kernel.org wrote:
>>
>> > On Tue, Dec 1, 2020 at 6:28
- On Dec 1, 2020, at 1:12 PM, Andy Lutomirski l...@kernel.org wrote:
> On Tue, Dec 1, 2020 at 6:28 AM Mathieu Desnoyers
> wrote:
>>
>> - On Dec 1, 2020, at 5:16 AM, Peter Zijlstra pet...@infradead.org wrote:
>>
>> > On Mon, Nov 30, 2020 at 09:50:
arriers. However, if another CPU switches to/from the
target mm concurrently with membarrier(), it can cause that CPU not to receive
the
IPI when it really should issue a memory barrier."
For the rest of this patch:
Reviewed-by: Mathieu Desnoyers
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
res done by the calling thread are visible
>> + * to the current task before the current task resumes. We could
>> + * probably optimize this away on most architectures, but by the
>> + * time we've already sent an IPI, the cost of the extra smp_mb()
>> + * is negligible.
>> + */
>> +smp_mb();
>> rseq_preempt(current);
>> }
>
> So I think this really isn't right.
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ditionally executed after we have sent the IPIs, and unconditionally
when issuing smp_call_function* on self.
About the documentation of the membarrier scenario, I think it is redundant
with a documentation patch I already have sitting in -tip (scenario A):
https://git.kernel.org/tip/25595eb6aaa9fbb31330f1e0b400642694bc6574
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
put in x86 lazy tlb code.
Ideally yes this complexity should sit within the x86 architecture code
if only that architecture requires it.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
put in x86 lazy tlb code.
Ideally yes this complexity should sit within the x86 architecture code
if only that architecture requires it.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
h about overhead of the consumer daemon, don't use live
mode, and use the alternatives we discussed earlier instead, such as the
session rotation mode, if you need to consume the trace data while it is
produced.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
g the "--live" option when
creating
the trace session. It will at least help identify whether consumerd also
exhibits this
cpu usage increase with number of cores in streaming mode, or if it is an
expected
additional overhead of periodically flushing more cpu buffers (because there
_worker_thread':
> param_test.c:1164: undefined reference to `rseq_offset_deref_addv'
> param_test.c:1164: undefined reference to `rseq_offset_deref_addv'
> collect2: error: ld returned 1 exit status
> make: *** [/selftests/rseq/param_test_benchmark] Error 1
>
> Signed-off-by: Xingxin
__string( name, regmap_name(map))
> __string( status, status )
> __string( type, type)
> - __field(int,type)
> ),
>
> TP_fast_assign(
> --
> 2.25.1
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
inal version.
It works for me. Bonus points if you can document in a comment that this
trick depends on the cdecl calling convention.
Thanks,
Mathieu
>
> This way Alexei can't complain about adding a check in the fast path of
> more than one callback attached.
>
> -- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
le at runtime when the actual
calls happen, this all works fine.
Thanks,
Mathieu
>
> -- Steve
>
>
> } while ((++it_func_ptr)->func);\
> return 0; \
> } \
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Nov 16, 2020, at 5:10 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 16 Nov 2020 16:34:41 -0500 (EST)
> Mathieu Desnoyers wrote:
[...]
>> I think you'll want a WRITE_ONCE(old[i].func, tp_stub_func) here, matched
>> with a READ_ONCE() in __DO_TRACE. This introduc
- On Nov 17, 2020, at 5:16 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 16:22:23 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> If we don't call the stub, then there is no point in having the stub at
>> all, and we should just compare to a constant valu
all the stub, then there is no point in having the stub at
all, and we should just compare to a constant value, e.g. 0x1UL. As far
as I can recall, comparing with a small immediate constant is more efficient
than comparing with a loaded value on many architectures.
Thanks,
Mathieu
--
Mathieu Desnoyers
Effici
- On Nov 17, 2020, at 3:34 PM, rostedt rost...@goodmis.org wrote:
> On Tue, 17 Nov 2020 14:47:20 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>> There seems to be more effect on the data size: adding the "stub_func" field
>> in struct tracepoint adds 8
; --- a/include/urcu/config.h.in
> +++ b/include/urcu/config.h.in
> @@ -28,7 +28,7 @@
> #undef CONFIG_RCU_FORCE_SYS_MEMBARRIER
>
> /* Enable internal debugging self-checks.
> - Introduce performance penalty. */
> + Introduces a performance penalty. */
> #undef CONFIG_RCU_D
501 - 600 of 11961 matches
Mail list logo
