* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
On 10/12, Andrew Morton wrote:
On Fri, 12 Oct 2007 15:47:59 -0400
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
Hi Andrew,
I noticed a regression between 2.6.23-rc8-mm2 and 2.6.23-mm1 (with your
hotfixes). User space threads seems
Network core events.
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
CC: netdev@vger.kernel.org
---
net/core/dev.c |5 +
net/ipv4/devinet.c |5 +
net/socket.c | 18 ++
3 files changed, 28 insertions(+)
Index: linux-2.6-lttng/net/core/dev.c
Network core events.
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
CC: netdev@vger.kernel.org
---
net/core/dev.c |5 +
net/ipv4/devinet.c |5 +
net/socket.c | 18 ++
3 files changed, 28 insertions(+)
Index: linux-2.6-lttng/net/core/dev.c
limits to ${limit}kbits, ${ctrlportlimit} for
control and ${dataportlimit} for data"
}
function reset_bw_limit
{
tc qdisc del dev $DEFAULT_IF root
echo "Reset bandwith limits"
}
trap reset_bw_limit SIGINT SIGTERM
set_bw_limit 3200
sleep 1
ping localhost
Signed-off
- On Feb 17, 2016, at 7:47 AM, Phil Sutter p...@nwl.cc wrote:
> Hi,
>
> On Tue, Feb 16, 2016 at 07:56:23PM -0500, Mathieu Desnoyers wrote:
>> This reverts commit 348e3435cbefa815bd56a5205c1412b5afe7b92e.
>> It breaks HTB classful qdiscs on the loopback interface.
>
ser-space, so it would "work".
But the guarantees provided by membarrier are not to synchronize against
preempt off per se. It's just that the current implementation happens to
do that. The point of membarrier is to turn user-space memory barriers
into compiler barriers.
If what you need is to wait for a RCU grace period for whatever RCU flavor
ebpf is using, I would against using membarrier for this. I would rather
recommend adding a dedicated BPF_SYNCHRONIZE so you won't leak
implementation details to user-space, *and* you can eventually change you
RCU implementation for e.g. SRCU in the future if needed.
Thanks,
Mathieu
>
> thanks!
>
> - Joel
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
>
> for some reason the start_bpf_raw_tp is off by 8.
> Not sure how it works for you.
>
> (gdb) p &__bpf_trace_tp_map_sys_exit
> $10 = (struct bpf_raw_event_map *) 0x84642440
> <__bpf_trace_tp_map_sys_exit>
>
> (gdb) p &__start__bpf_raw_tp
> $7 = ( *) 0xfff
- On Mar 27, 2018, at 8:00 PM, Alexei Starovoitov a...@fb.com wrote:
> On 3/27/18 4:13 PM, Mathieu Desnoyers wrote:
>> - On Mar 27, 2018, at 6:48 PM, Alexei Starovoitov a...@fb.com wrote:
>>
>>> On 3/27/18 2:04 PM, Steven Rostedt wrote:
>>>>
>>
find_by_name() at some
point (starting with a tracepoint_ prefix). I'm find with either of
the names.
Reviewed-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
Thanks,
Mathieu
>
> Thanks for doing this Alexei!
>
> One nit below.
>
>
>> ---
>> includ
- On Mar 27, 2018, at 11:53 AM, Alexei Starovoitov a...@fb.com wrote:
> On 3/27/18 7:42 AM, Steven Rostedt wrote:
>> On Tue, 27 Mar 2018 10:18:24 -0400 (EDT)
>> Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
>>
>>> - On Mar 27, 2018, at 1
h as well
>> and reduce memory footprint.
>
> If Linus, Thomas, Peter, Ingo, and the security folks trust kallsyms to
> return a valid function pointer from a name, then sure, we can try
> going that way.
This will crash on ARM Thumb2 kernels. Also, how is this expected to
work on PowerPC ABIv1 without KALLSYMS_ALL ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
and got delayed but this set.
>
> Then by all means, you have my Ack. We can optimize later.
>
> For the whole series... (v7 or v8)
>
> Acked-by: Steven Rostedt (VMware) <rost...@goodmis.org>
I'm fine with either v7 or v8 as well.
Thanks,
Mathieu
>
> Thanks!
>
> -- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- Steve
>
>
>> if (it_func_ptr) { \
> > do {\
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Mar 28, 2018, at 12:43 PM, Alexei Starovoitov a...@fb.com wrote:
> On 3/28/18 6:49 AM, Mathieu Desnoyers wrote:
>> - On Mar 27, 2018, at 10:11 PM, Alexei Starovoitov a...@fb.com wrote:
>>
>>> From: Alexei Starovoitov <a...@kernel.org>
>>>
ready macros heavy code.
>> Also what it will address?
>
> 32bit bloat ;-)
>
> But I agree, it's not worth uglifying it.
>
> -- Steve
>
> > cache hot/cold argument clearly doesn't apply.
In the current situation I'm fine with adding this extra field
to struct tra
hat are Alexei's plan to handle tracepoints
in modules, considering module load/unload scenarios ? The tracepoint API
has module notifiers for this, but it does not appear to be used in this
patch series.
Thanks,
Mathieu
>
> -- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Mar 26, 2018, at 12:08 PM, Alexei Starovoitov a...@fb.com wrote:
> On 3/26/18 8:55 AM, Mathieu Desnoyers wrote:
>> - On Mar 26, 2018, at 11:42 AM, Alexei Starovoitov a...@fb.com wrote:
>>
>>> On 3/26/18 8:14 AM, Mathieu Desnoyers wrote:
>>>>
ruct tracepoint *tp, void
>> *priv),
>> + void *priv)
>> {
>> struct tracepoint * const *iter;
>> + void *ret;
>>
>> if (!begin)
>> -return;
>> -for (iter = begin; iter < end; iter++)
>> -fct(*iter, priv);
>> +return NULL;
>> +for (iter = begin; iter < end; iter++) {
>> +ret = fct(*iter, priv);
>> +if (ret)
>> +return ret;
>> +}
>> +return NULL;
>> }
>>
>> /**
>> @@ -520,11 +525,11 @@ static void for_each_tracepoint_range(struct
>> tracepoint *
>> const *begin,
>> * @fct: callback
>> * @priv: private data
>> */
>> -void for_each_kernel_tracepoint(void (*fct)(struct tracepoint *tp, void
>> *priv),
>> -void *priv)
>> +void *for_each_kernel_tracepoint(void *(*fct)(struct tracepoint *tp, void
>> *priv),
>> + void *priv)
>> {
>> -for_each_tracepoint_range(__start___tracepoints_ptrs,
>> -__stop___tracepoints_ptrs, fct, priv);
>> +return for_each_tracepoint_range(__start___tracepoints_ptrs,
>> + __stop___tracepoints_ptrs, fct, priv);
>> }
>> EXPORT_SYMBOL_GPL(for_each_kernel_tracepoint);
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Mar 26, 2018, at 11:42 AM, Alexei Starovoitov a...@fb.com wrote:
> On 3/26/18 8:14 AM, Mathieu Desnoyers wrote:
>> - On Mar 26, 2018, at 11:02 AM, rostedt rost...@goodmis.org wrote:
>>
>>> On Fri, 23 Mar 2018 19:30:34 -0700
>>> Alexei Starovoitov &
t; #undef DEFINE_EVENT_PRINT
> #define DEFINE_EVENT_PRINT(template, name, proto, args, print)\
> - DEFINE_TRACE(name)
> + DEFINE_TRACE(name, COUNT_ARGS(args))
>
> #undef DEFINE_EVENT_CONDITION
> #define DEFINE_EVENT_CONDITION(template, name, proto, args, cond) \
> @@ -64,7 +64,7 @@
>
> #undef DECLARE_TRACE
> #define DECLARE_TRACE(name, proto, args) \
> - DEFINE_TRACE(name)
> + DEFINE_TRACE(name, COUNT_ARGS(args))
>
> #undef TRACE_INCLUDE
> #undef __TRACE_INCLUDE
> --
> 2.9.5
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
cpoints are.
> No wonder some maintainers refuse to add them.
Since when has it become accepted to push commits into maintainer's
subsystems without their acknowledgment first ?
The minefield you are currently walking through appears to be of your
own making, so please just rework your initial patch before it reaches
upstream.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
S=n before submitting a patch involving tracepoints.
But this patch should not even be needed in the first place, because it
partially reverts changes that were introduced in the bpf-next tree without
any Acked-by from the tracing maintainers. I don't see any need to obfuscate
the git log of tracepo
changelog is fine
with me. Please submit it as a separate commit from the rest
of the tracepoint.{c,h} changes.
[...]
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ysis, so I think
the use case justifies adding the missing "exit" events.
It might be great if you can provide a glimpse of the wakeup dependency chain
analysis prototypes you have created, which rely on this new event, in order
to justify adding it.
Thanks,
Mathieu
>
> Signed-of
ge.
Also, I wonder if we should use "net_dev_template_exit" for the event
class rather than "net_dev_template_return" ?
Thanks,
Mathieu
>
> Signed-off-by: Geneviève Bastien
> CC: Mathieu Desnoyers
> CC: Steven Rostedt
> CC: Ingo Molnar
> CC: David S. Mil
- On Nov 12, 2018, at 3:09 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 12, 2018, at 2:44 PM, Geneviève Bastien gbast...@versatic.net
> wrote:
>
>> Trace events are already present for the receive entry points, to indicate
>> how the recept
- On Nov 12, 2018, at 3:20 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 12, 2018, at 3:09 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> - On Nov 12, 2018, at 2:44 PM, Geneviève Bastien gbast...@versatic.net
>>
- On Nov 12, 2018, at 3:40 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 12 Nov 2018 15:20:55 -0500 (EST)
> Mathieu Desnoyers wrote:
>
>>
>> Hrm, looking at this again, I notice that there is a single DEFINE_EVENT
>> using net_dev_template_simple.
- On Nov 12, 2018, at 3:46 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Nov 12, 2018, at 3:40 PM, rostedt rost...@goodmis.org wrote:
>
>> On Mon, 12 Nov 2018 15:20:55 -0500 (EST)
>> Mathieu Desnoyers wrote:
>>
>>>
>>
d at the specifics
though, so I may be wrong.)
Do you have a preference between those two approaches, or perhaps you
have an alternative solution in mind ?
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
30 matches
Mail list logo
