linux perf record: difference between count (-c) and frequency (-F) options












0















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?










share|improve this question























  • 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


















0















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?










share|improve this question























  • 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
















0












0








0








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?










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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 of perf 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











  • 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



















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














1 Answer
1






active

oldest

votes


















4














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.






share|improve this answer
























  • 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













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
});


}
});














draft saved

draft discarded


















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









4














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.






share|improve this answer
























  • 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


















4














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.






share|improve this answer
























  • 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
















4












4








4







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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





















  • 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






















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Tonle Sap (See)

I get strange results when I access the Sqlitedatabase with Unity C# via XAMPP

Guatemaltekische Davis-Cup-Mannschaft