> The following tcp tracepoints are updated:
> > tcp:tcp_destroy_sock
> > tcp:tcp_rcv_space_adjust
> > tcp:tcp_retransmit_skb
> > tcp:tcp_send_reset
> > tcp:tcp_receive_reset
> > tcp:tcp_retransmit_synack
> > tcp:tcp_probe
> >
> > Signed-of
> > * inside its own verifier_ops->get_func_proto() callback it should
> > > return
> > > @@ -364,3 +365,34 @@ const struct bpf_func_proto
> > > bpf_get_local_storage_proto = {
> > > };
> > > #endif
> > > #endif
> > > +
> > > +BPF_CALL_1(bpf_progenyof, int, pid)
> >
> > Nit: could we add a more descriptive helper name? What's progenyof? Also
> > s/int/pid_t/?
> >
>
> It's true that "progeny" is not a very commonly used word :D. A coworker
> suggested "descendantof", what do you think? It's a bit difficult to
> convey "is true on the passed pid + on all the process under the
> hierarchy chain of that pid", so I will try rewording the docs so the
> semantics are very clear!
What about childof? I see the word child used more than anything:
$ man ps pgrep pidstat pstree top | grep child | wc -l
29
$ man ps pgrep pidstat pstree top | grep progeny | wc -l
0
$ man ps pgrep pidstat pstree top | grep ancestor | wc -l
2
Brendan
--
Brendan Gregg, Senior Performance Architect, Netflix
On Tue, Mar 12, 2019 at 9:54 AM Kris Van Hees wrote:
>
> On Mon, Mar 11, 2019 at 11:03:10PM -0700, Brendan Gregg wrote:
> > On Mon, Mar 11, 2019 at 8:24 PM Kris Van Hees
> > wrote:
> > >
> > > On Mon, Mar 11, 2019 at 06:29:55PM -0700, Brendan Gregg wrote:
>
On Mon, Mar 11, 2019 at 8:24 PM Kris Van Hees wrote:
>
> On Mon, Mar 11, 2019 at 06:29:55PM -0700, Brendan Gregg wrote:
> > On Mon, Mar 11, 2019 at 7:21 AM Kris Van Hees
> > wrote:
> > >
> > > On Thu, Mar 07, 2019 at 01:30:37PM -0800, Alexei Starovoitov wrote
m currently doing workarounds for,
like ppid, but that should be satisfied with a few more helpers. And
if it's really niche, then BTF sounds like a good solution.
If your ultimate goal is to have a command called "dtrace" that runs D
programs, to support your existing users, then I'd add a lex/yacc pair
to bpftrace and have it emit a dtrace binary.
Brendan
--
Brendan Gregg, Senior Performance Architect, Netflix
On Sat, Dec 30, 2017 at 7:06 PM, Yafang Shao wrote:
> On Sun, Dec 31, 2017 at 6:33 AM, Brendan Gregg
> wrote:
>> On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao wrote:
>>> As sk_state is a common field for struct sock, so the state
>>> transition tracepoint should
On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao wrote:
> As sk_state is a common field for struct sock, so the state
> transition tracepoint should not be a TCP specific feature.
> Currently it traces all AF_INET state transition, so I rename this
> tracepoint to inet_sock_set_state tracepoint with s
On Fri, Oct 13, 2017 at 3:09 PM, Alexei Starovoitov
wrote:
> On Fri, Oct 13, 2017 at 01:50:44PM -0700, Brendan Gregg wrote:
>> On Fri, Oct 13, 2017 at 1:03 PM, Cong Wang wrote:
>> > We need a real-time notification for tcp retransmission
>> > for monitoring.
>&
On Fri, Oct 13, 2017 at 1:03 PM, Cong Wang wrote:
> We need a real-time notification for tcp retransmission
> for monitoring.
>
> Of course we could use ftrace to dynamically instrument this
> kernel function too, however we can't retrieve the connection
> information at the same time, for example
at we discussed.
>
> Patches 1-3 is bpf-side prep for the main patch 4
> that adds bpf program as an overflow_handler to sw and hw perf_events.
> Peter, please review.
>
> Patches 5 and 6 are examples from myself and Brendan.
>
> v1-v2: fixed issues spotted by Peter and Daniel.
T
On Mon, Aug 29, 2016 at 5:19 AM, Peter Zijlstra wrote:
>
> On Fri, Aug 26, 2016 at 07:31:18PM -0700, Alexei Starovoitov wrote:
> > Hi Peter, Dave,
> >
> > this patch set is a follow up to the discussion:
> > https://lkml.org/lkml/2016/8/4/304
> > It turned out to be simpler than what we discussed.
11 matches
Mail list logo
