linux perf record: difference between count (-c) and frequency (-F) options
I'm trying to understand what the -c and -F options of perf record really do but I cannot explain what I'm seeing. I'm running these commands:
perf record -a -F <frequency> sleep 1
and
perf record -a -c <count> sleep 1
trying different values of frequency and count. The results I get are
the following
In the first table I set the frequency and in the second one the count. How do frequency and count affect the number of events? I thought the number of events was independent on the frequency and count, but clearly it's not the case. What does perf actually do?
linux count frequency perf
add a comment |
I'm trying to understand what the -c and -F options of perf record really do but I cannot explain what I'm seeing. I'm running these commands:
perf record -a -F <frequency> sleep 1
and
perf record -a -c <count> sleep 1
trying different values of frequency and count. The results I get are
the following
In the first table I set the frequency and in the second one the count. How do frequency and count affect the number of events? I thought the number of events was independent on the frequency and count, but clearly it's not the case. What does perf actually do?
linux count frequency perf
How did you get "samples" and "events" in your table?
– Zulan
Nov 23 '18 at 16:12
It is very likely obtained with the help ofperf report.
– Arnabjyoti Kalita
Nov 24 '18 at 2:08
Yes, I used perf report
– S. Rinco
Nov 26 '18 at 9:20
add a comment |
I'm trying to understand what the -c and -F options of perf record really do but I cannot explain what I'm seeing. I'm running these commands:
perf record -a -F <frequency> sleep 1
and
perf record -a -c <count> sleep 1
trying different values of frequency and count. The results I get are
the following
In the first table I set the frequency and in the second one the count. How do frequency and count affect the number of events? I thought the number of events was independent on the frequency and count, but clearly it's not the case. What does perf actually do?
linux count frequency perf
I'm trying to understand what the -c and -F options of perf record really do but I cannot explain what I'm seeing. I'm running these commands:
perf record -a -F <frequency> sleep 1
and
perf record -a -c <count> sleep 1
trying different values of frequency and count. The results I get are
the following
In the first table I set the frequency and in the second one the count. How do frequency and count affect the number of events? I thought the number of events was independent on the frequency and count, but clearly it's not the case. What does perf actually do?
linux count frequency perf
linux count frequency perf
asked Nov 23 '18 at 15:04
S. RincoS. Rinco
32
32
How did you get "samples" and "events" in your table?
– Zulan
Nov 23 '18 at 16:12
It is very likely obtained with the help ofperf report.
– Arnabjyoti Kalita
Nov 24 '18 at 2:08
Yes, I used perf report
– S. Rinco
Nov 26 '18 at 9:20
add a comment |
How did you get "samples" and "events" in your table?
– Zulan
Nov 23 '18 at 16:12
It is very likely obtained with the help ofperf report.
– Arnabjyoti Kalita
Nov 24 '18 at 2:08
Yes, I used perf report
– S. Rinco
Nov 26 '18 at 9:20
How did you get "samples" and "events" in your table?
– Zulan
Nov 23 '18 at 16:12
How did you get "samples" and "events" in your table?
– Zulan
Nov 23 '18 at 16:12
It is very likely obtained with the help of
perf report.– Arnabjyoti Kalita
Nov 24 '18 at 2:08
It is very likely obtained with the help of
perf report.– Arnabjyoti Kalita
Nov 24 '18 at 2:08
Yes, I used perf report
– S. Rinco
Nov 26 '18 at 9:20
Yes, I used perf report
– S. Rinco
Nov 26 '18 at 9:20
add a comment |
1 Answer
1
active
oldest
votes
Count and frequency are two fundamental switches that tune the rate of sampling when using perf record (which does sampling internally).
Count
When you run perf record -c <number>, you are specifying the sample period (where "number" is the sample period). That is, for every "number"th occurrence of the event a sample will be recorded. The sample will be recorded when the performance counter that keeps track of the number of events has overflowed.
I am guessing you are obtaining the number of events with the help of perf report. Note that perf report will never report the actual number of events, but only an approximate. The number of events will keep changing as you keep tweaking the sample period. perf report will only read the perf.data file that perf record generates, and based on the size of the file generated, it makes an assumption of the number of samples recorded (by knowing the size of a sample recorded in memory). The actual number of events recorded is obtained by -
Number of events = Fixed Sample Period * Number of samples collected
where Fixed Sample Period is what you specified with perf record -c.
Frequency
This is the other way around to express the sampling period, that is to specify the average rate of samples per second (frequency) - which you can do using perf record -F. So perf record -F 1000 will record around 1000 samples per second and these samples will be generated when the hardware/PMU counter corresponding to the event overflows. This means that the kernel will dynamically adjust the sampling period to make sure that the sampling process adheres to the sampling frequency.
This is how the sample period gets updated dynamically.
Higher the sampling frequency, higher the number of samples collected (almost proportionately).
The variation in the sampling period can be seen by running the command -
sudo perf report -D -i perf.data | fgrep RECORD_SAMPLE
Whenever the sampling period keeps varying, the total number of events will keep incrementing with the variation in the sampling period. And when the sampling period remains fixed, the total number of events remain fixed and is obtained by the formula showed above. The total number of events will be approximate in both the cases.
What you explained is correct but doesn't explain the results I obtained. What I expect to see with the -F option is that the number of samples is directly proportional to the frequency and #samples/frequency is the total runtime of the program. The number of events should be constant. With the -c option count x samples should be very close to the number of events seen with the -F option. In order to reproduce this I had to pass an event (-e cycles for instance) and use a value of count high enough. I think perf uses a min value if you pass a very small number, without telling you
– S. Rinco
Nov 26 '18 at 11:16
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53449001%2flinux-perf-record-difference-between-count-c-and-frequency-f-options%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Count and frequency are two fundamental switches that tune the rate of sampling when using perf record (which does sampling internally).
Count
When you run perf record -c <number>, you are specifying the sample period (where "number" is the sample period). That is, for every "number"th occurrence of the event a sample will be recorded. The sample will be recorded when the performance counter that keeps track of the number of events has overflowed.
I am guessing you are obtaining the number of events with the help of perf report. Note that perf report will never report the actual number of events, but only an approximate. The number of events will keep changing as you keep tweaking the sample period. perf report will only read the perf.data file that perf record generates, and based on the size of the file generated, it makes an assumption of the number of samples recorded (by knowing the size of a sample recorded in memory). The actual number of events recorded is obtained by -
Number of events = Fixed Sample Period * Number of samples collected
where Fixed Sample Period is what you specified with perf record -c.
Frequency
This is the other way around to express the sampling period, that is to specify the average rate of samples per second (frequency) - which you can do using perf record -F. So perf record -F 1000 will record around 1000 samples per second and these samples will be generated when the hardware/PMU counter corresponding to the event overflows. This means that the kernel will dynamically adjust the sampling period to make sure that the sampling process adheres to the sampling frequency.
This is how the sample period gets updated dynamically.
Higher the sampling frequency, higher the number of samples collected (almost proportionately).
The variation in the sampling period can be seen by running the command -
sudo perf report -D -i perf.data | fgrep RECORD_SAMPLE
Whenever the sampling period keeps varying, the total number of events will keep incrementing with the variation in the sampling period. And when the sampling period remains fixed, the total number of events remain fixed and is obtained by the formula showed above. The total number of events will be approximate in both the cases.
What you explained is correct but doesn't explain the results I obtained. What I expect to see with the -F option is that the number of samples is directly proportional to the frequency and #samples/frequency is the total runtime of the program. The number of events should be constant. With the -c option count x samples should be very close to the number of events seen with the -F option. In order to reproduce this I had to pass an event (-e cycles for instance) and use a value of count high enough. I think perf uses a min value if you pass a very small number, without telling you
– S. Rinco
Nov 26 '18 at 11:16
add a comment |
Count and frequency are two fundamental switches that tune the rate of sampling when using perf record (which does sampling internally).
Count
When you run perf record -c <number>, you are specifying the sample period (where "number" is the sample period). That is, for every "number"th occurrence of the event a sample will be recorded. The sample will be recorded when the performance counter that keeps track of the number of events has overflowed.
I am guessing you are obtaining the number of events with the help of perf report. Note that perf report will never report the actual number of events, but only an approximate. The number of events will keep changing as you keep tweaking the sample period. perf report will only read the perf.data file that perf record generates, and based on the size of the file generated, it makes an assumption of the number of samples recorded (by knowing the size of a sample recorded in memory). The actual number of events recorded is obtained by -
Number of events = Fixed Sample Period * Number of samples collected
where Fixed Sample Period is what you specified with perf record -c.
Frequency
This is the other way around to express the sampling period, that is to specify the average rate of samples per second (frequency) - which you can do using perf record -F. So perf record -F 1000 will record around 1000 samples per second and these samples will be generated when the hardware/PMU counter corresponding to the event overflows. This means that the kernel will dynamically adjust the sampling period to make sure that the sampling process adheres to the sampling frequency.
This is how the sample period gets updated dynamically.
Higher the sampling frequency, higher the number of samples collected (almost proportionately).
The variation in the sampling period can be seen by running the command -
sudo perf report -D -i perf.data | fgrep RECORD_SAMPLE
Whenever the sampling period keeps varying, the total number of events will keep incrementing with the variation in the sampling period. And when the sampling period remains fixed, the total number of events remain fixed and is obtained by the formula showed above. The total number of events will be approximate in both the cases.
What you explained is correct but doesn't explain the results I obtained. What I expect to see with the -F option is that the number of samples is directly proportional to the frequency and #samples/frequency is the total runtime of the program. The number of events should be constant. With the -c option count x samples should be very close to the number of events seen with the -F option. In order to reproduce this I had to pass an event (-e cycles for instance) and use a value of count high enough. I think perf uses a min value if you pass a very small number, without telling you
– S. Rinco
Nov 26 '18 at 11:16
add a comment |
Count and frequency are two fundamental switches that tune the rate of sampling when using perf record (which does sampling internally).
Count
When you run perf record -c <number>, you are specifying the sample period (where "number" is the sample period). That is, for every "number"th occurrence of the event a sample will be recorded. The sample will be recorded when the performance counter that keeps track of the number of events has overflowed.
I am guessing you are obtaining the number of events with the help of perf report. Note that perf report will never report the actual number of events, but only an approximate. The number of events will keep changing as you keep tweaking the sample period. perf report will only read the perf.data file that perf record generates, and based on the size of the file generated, it makes an assumption of the number of samples recorded (by knowing the size of a sample recorded in memory). The actual number of events recorded is obtained by -
Number of events = Fixed Sample Period * Number of samples collected
where Fixed Sample Period is what you specified with perf record -c.
Frequency
This is the other way around to express the sampling period, that is to specify the average rate of samples per second (frequency) - which you can do using perf record -F. So perf record -F 1000 will record around 1000 samples per second and these samples will be generated when the hardware/PMU counter corresponding to the event overflows. This means that the kernel will dynamically adjust the sampling period to make sure that the sampling process adheres to the sampling frequency.
This is how the sample period gets updated dynamically.
Higher the sampling frequency, higher the number of samples collected (almost proportionately).
The variation in the sampling period can be seen by running the command -
sudo perf report -D -i perf.data | fgrep RECORD_SAMPLE
Whenever the sampling period keeps varying, the total number of events will keep incrementing with the variation in the sampling period. And when the sampling period remains fixed, the total number of events remain fixed and is obtained by the formula showed above. The total number of events will be approximate in both the cases.
Count and frequency are two fundamental switches that tune the rate of sampling when using perf record (which does sampling internally).
Count
When you run perf record -c <number>, you are specifying the sample period (where "number" is the sample period). That is, for every "number"th occurrence of the event a sample will be recorded. The sample will be recorded when the performance counter that keeps track of the number of events has overflowed.
I am guessing you are obtaining the number of events with the help of perf report. Note that perf report will never report the actual number of events, but only an approximate. The number of events will keep changing as you keep tweaking the sample period. perf report will only read the perf.data file that perf record generates, and based on the size of the file generated, it makes an assumption of the number of samples recorded (by knowing the size of a sample recorded in memory). The actual number of events recorded is obtained by -
Number of events = Fixed Sample Period * Number of samples collected
where Fixed Sample Period is what you specified with perf record -c.
Frequency
This is the other way around to express the sampling period, that is to specify the average rate of samples per second (frequency) - which you can do using perf record -F. So perf record -F 1000 will record around 1000 samples per second and these samples will be generated when the hardware/PMU counter corresponding to the event overflows. This means that the kernel will dynamically adjust the sampling period to make sure that the sampling process adheres to the sampling frequency.
This is how the sample period gets updated dynamically.
Higher the sampling frequency, higher the number of samples collected (almost proportionately).
The variation in the sampling period can be seen by running the command -
sudo perf report -D -i perf.data | fgrep RECORD_SAMPLE
Whenever the sampling period keeps varying, the total number of events will keep incrementing with the variation in the sampling period. And when the sampling period remains fixed, the total number of events remain fixed and is obtained by the formula showed above. The total number of events will be approximate in both the cases.
answered Nov 24 '18 at 4:06
Arnabjyoti KalitaArnabjyoti Kalita
7931618
7931618
What you explained is correct but doesn't explain the results I obtained. What I expect to see with the -F option is that the number of samples is directly proportional to the frequency and #samples/frequency is the total runtime of the program. The number of events should be constant. With the -c option count x samples should be very close to the number of events seen with the -F option. In order to reproduce this I had to pass an event (-e cycles for instance) and use a value of count high enough. I think perf uses a min value if you pass a very small number, without telling you
– S. Rinco
Nov 26 '18 at 11:16
add a comment |
What you explained is correct but doesn't explain the results I obtained. What I expect to see with the -F option is that the number of samples is directly proportional to the frequency and #samples/frequency is the total runtime of the program. The number of events should be constant. With the -c option count x samples should be very close to the number of events seen with the -F option. In order to reproduce this I had to pass an event (-e cycles for instance) and use a value of count high enough. I think perf uses a min value if you pass a very small number, without telling you
– S. Rinco
Nov 26 '18 at 11:16
What you explained is correct but doesn't explain the results I obtained. What I expect to see with the -F option is that the number of samples is directly proportional to the frequency and #samples/frequency is the total runtime of the program. The number of events should be constant. With the -c option count x samples should be very close to the number of events seen with the -F option. In order to reproduce this I had to pass an event (-e cycles for instance) and use a value of count high enough. I think perf uses a min value if you pass a very small number, without telling you
– S. Rinco
Nov 26 '18 at 11:16
What you explained is correct but doesn't explain the results I obtained. What I expect to see with the -F option is that the number of samples is directly proportional to the frequency and #samples/frequency is the total runtime of the program. The number of events should be constant. With the -c option count x samples should be very close to the number of events seen with the -F option. In order to reproduce this I had to pass an event (-e cycles for instance) and use a value of count high enough. I think perf uses a min value if you pass a very small number, without telling you
– S. Rinco
Nov 26 '18 at 11:16
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53449001%2flinux-perf-record-difference-between-count-c-and-frequency-f-options%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
How did you get "samples" and "events" in your table?
– Zulan
Nov 23 '18 at 16:12
It is very likely obtained with the help of
perf report.– Arnabjyoti Kalita
Nov 24 '18 at 2:08
Yes, I used perf report
– S. Rinco
Nov 26 '18 at 9:20