kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: Pedro Terra Delboni <terra0009@gmail.com>
To: kernelnewbies@kernelnewbies.org
Subject: Re: how to collect information regarding function calls in run time?
Date: Tue, 14 May 2019 10:55:40 -0300	[thread overview]
Message-ID: <CAHKDPP8hGP=N_NVpND8AUeUtOCq77Nr6owy-wH9iD_k3tfs=9Q@mail.gmail.com> (raw)
In-Reply-To: <CADFy_4FJODA9gT7Enb+eLt-bdJBkkgTmqhhb3AhJhjibgbzD2A@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3373 bytes --]

Sorry to revive this old thread, and thank you for the suggestions given,
but I've been trying to make these work for my case with little success and
I need a hand to understand what I'm doing wrong.

Regarding bpftrace: This seemed like the best option since I could use it
to count frames of the stack with depth 2, allowing me to know precisely
the amount of times each specific call has been made. However, I could not
use it because since I have to probe every function, it would raise an
error related to open file limit. I've tried setting the open file limit to
unlimited, but the command I used to do so said it was impossible, also the
current limit is set to 1048576, so I'm guessing that probing every
function isn't a viable solution.

Regarding perf: I couldn't find out how to count each call with perf, but I
could count how many times each function was called. Differently from
bpftrace, I need to use a command for each function I would like to probe,
so I created a script that would get all the functions that can be probed
and call that command for each of them. Unfortunately this took too long,
so I stopped after a certain number of probes were created and executed my
test, at that time, the machine hanged.
With a low number of functions being probed it worked fine though.

Right now, the solution I can see is using bpftrace to probe a very limited
number of calls, profile an execution, then repeat the profile for
different set of probes, which can take a very long time.
Is there an easier way (less time consuming) to achieve the same results
(counting how many times each call instruction has been executed)?

Thanks you for the attention,
Pedro

On Wed, Apr 3, 2019 at 6:23 PM Augusto Mecking Caringi <
augustocaringi@gmail.com> wrote:

> Hi,
>
> On Wed, Apr 3, 2019 at 9:26 PM Pedro Terra Delboni <terra0009@gmail.com>
> wrote:
> >
> > Hello!
> >
> > I have a question about profiling, please, let me know if this is not
> > the right mailing list to post these kind of questions.
> >
> > Is there a way for me to record how many times each specific direct
> > call to a function happened?
> > I've seen ways of profiling the kernel that calculate how much time
> > the system spent in each function, but having a bit more information
> > related to calls would be really good.
> >
> > I would like to know, for every function call that happens in run
> > time, who called it (it's for a project in my University).
> >
> > I've also seen (I may be mistaken here) that by compiling the kernel
> > with perf, each function will start with a stub call which can be used
> > for profiling purposes.
> > I was thinking in using this stub to plug a function to dump
> > (somewhere) the return address before it's own (so I can collect the
> > info about where the call came from).
> > I wonder if changing every stub calls in all functions to dump its
> > return address wouldn't create too much of a latency impact to the
> > point of skewing the control flow of the execution,
> > or even making it nonviable.
> >
> > Thanks in advance, any help would be great!
> > If this is not the right place to post this question, I would
> > appreciate if anyone could point me to the right place.
>
> There is also a new tool called bpftrace that can help you...
>
> https://github.com/iovisor/bpftrace
>
> Regards,
>
> --
> Augusto Mecking Caringi
>

[-- Attachment #1.2: Type: text/html, Size: 4267 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  parent reply	other threads:[~2019-05-14 13:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03 19:25 how to collect information regarding function calls in run time? Pedro Terra Delboni
2019-04-03 20:15 ` Bharath Vedartham
     [not found] ` <CADFy_4FJODA9gT7Enb+eLt-bdJBkkgTmqhhb3AhJhjibgbzD2A@mail.gmail.com>
2019-05-14 13:55   ` Pedro Terra Delboni [this message]
2019-05-14 14:05     ` Greg KH
2019-05-14 14:14       ` Pedro Terra Delboni
2019-05-14 17:45     ` Valdis Klētnieks
2019-05-14 19:11       ` Pedro Terra Delboni
2019-05-17 14:09         ` Valdis Klētnieks
2019-05-17 16:19           ` Pedro Terra Delboni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHKDPP8hGP=N_NVpND8AUeUtOCq77Nr6owy-wH9iD_k3tfs=9Q@mail.gmail.com' \
    --to=terra0009@gmail.com \
    --cc=kernelnewbies@kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).