From: SeongJae Park <sj@kernel.org>
To: Vinicius Petrucci <vpetrucci@gmail.com>
Cc: damon@lists.linux.dev
Subject: Re: Issue while testing new fvaddr feature
Date: Wed, 19 Oct 2022 17:45:10 +0000 [thread overview]
Message-ID: <20221019174510.85286-1-sj@kernel.org> (raw)
In-Reply-To: <CAEZ6=UNUcH2BvJj++OrT=XQLdkidU79wmCO=tantSOB36pPNTg@mail.gmail.com>
Hi Vinicius,
On Tue, 18 Oct 2022 21:49:22 -0500 Vinicius Petrucci <vpetrucci@gmail.com> wrote:
> Hello,
>
> I am experimenting with the new fixed address (fvaddr) feature of
> DAMON to monitor memory regions originated from user-level mmap/malloc
> calls.
> I used "strace" to intercept the mmap calls and derive "start" and
> "end" attributes for monitoring using the "masim" program
> (https://github.com/sjp38/masim) as an example that creates two memory
> allocations and keeps accessing them for a long time.
> Then, I used "perf record" to get the data, but perf doesn't seem to
> be recording anything. Nothing is shown after issuing "perf script".
>
> Could you please help me spot any mistakes with my tests (if any)
> using the Bash script below? Could also please let me know whether or
> not that is reproducible in your system?
>
> I am using kernel 6.0.2 and I checked that "fvaddr" is supported via
> "damo features".
> All steps in the script below ("test-fvaddr-damon.sh") runs without
> any errors. It is just that nothing appears in the perf data.
Thank you for reaching out to us with this kind question!
>
> -------- test-fvaddr-damon.sh --------------
>
> strace -e mmap ./masim/masim hint_test_inf 2> strace.out &
>
>
> sleep 2
>
>
> echo 1 > /sys/kernel/mm/damon/admin/kdamonds/nr_kdamonds
> echo 1 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/nr_contexts
>
> echo fvaddr > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/operations
>
> echo 1 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/nr_targets
>
> echo $(pidof masim) >
> /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/0/pid_target
>
> echo on > /sys/kernel/mm/damon/admin/kdamonds/0/state
>
>
>
> start1=`cat strace.out | tail -2 | head -1 | cut -f2 -d=`
>
> start2=`cat strace.out | tail -2 | tail -1 | cut -f2 -d=`
>
>
>
> # convert to decimal
>
> start1=$((${start1}))
>
> start2=$((${start2}))
>
>
>
> size1=`cat strace.out | tail -2 | cut -d, -f2 | head -1`
>
> size2=`cat strace.out | tail -2 | cut -d, -f2 | tail -1`
>
>
>
> end1=$(($start1+$size1-1))
>
> end2=$(($start1+$size1-1))
>
>
>
> echo $start1 $end1
>
> echo $start2 $end2
>
>
>
> echo 2 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/0/regions/nr_regions
>
>
>
> echo $start1 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/0/regions/0/start
>
> echo $end1 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/0/regions/0/end
>
>
>
> echo $start2 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/0/regions/1/start
>
> echo $end2 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/0/regions/1/end
>
>
>
> perf record -e damon:damon_aggregated &
kdamond doesn't read the values of the sysfs files after turned on by default.
You can force it to read the values again by writing a special keyword,
`commit`, to the `state` file of the kdamond[1].
Therefore, in this case, DAMON would run with no region, and hence it gets
nothing to report. I think that should be why you show nothing from the `perf
script` command.
So, could you please set the start/end values before turning the kdamond on, or
write 'commit' to the 'state' file here, and check if it works?
If there is anything I missed or wrong, please let me know.
[1] https://www.kernel.org/doc/html/v6.0/admin-guide/mm/damon/usage.html#kdamonds-n
Thanks,
SJ
>
>
>
> sleep 15
>
>
>
> kill $(pidof perf)
>
>
>
> echo off > /sys/kernel/mm/damon/admin/kdamonds/0/state
>
>
>
> perf script
>
>
>
> killall strace
>
> ----------- hint_test_inf -------------
>
> #regions
>
> # name, length
>
> a, 1073741824 # 1 GiB
>
> b, 1073741824 # 1 GiB
>
>
>
> # phase 1
>
> # name of phase
>
> phase 1
>
> # time in ms
>
> 9999999999999
>
> # access patterns
>
> # name of region, randomness, stride, probability
>
> a, 0, 64, 99
>
> b, 0, 64, 1
>
>
>
> # phase 2
>
> phase 2
>
> # time in ms
>
> 10000
>
> # access patterns
>
> # name of region, randomness, stride, probability
>
> a, 0, 64, 1
>
> b, 0, 64, 99
>
>
> Thank you!
next prev parent reply other threads:[~2022-10-19 17:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 2:49 Issue while testing new fvaddr feature Vinicius Petrucci
2022-10-19 17:45 ` SeongJae Park [this message]
2022-10-19 23:58 ` Vinicius Petrucci
2022-10-20 0:43 ` SeongJae Park
2022-10-20 1:17 ` Vinicius Petrucci
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=20221019174510.85286-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=damon@lists.linux.dev \
--cc=vpetrucci@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.