Hi,
On Wed, May 13, 2009 at 11:21 AM, Juan Angel Lorenzo
<jalmailingli...@gmail.com> wrote:
> Hi Eranian,
>
> Thanks for your quick reply. Reading your comments they make me think
> that perhaps I have a mistaken idea of how the sampling buffer works.
> Correct me if I'm wrong but I understood that, when an EAR overflows
EAR does not overflow. The counter counting the number of captured EAR
events overflows.
> (and it'll do it sooner or later depending on the sampling period and
> the number of events in the code), the data from PMDs 32,33 and 36 are
> stored as an entry in the kernel sampling buffer. This goes on until the
> buffer is full (when all the collected entries reach a whole size as
> large as a page size or whatever size we set in the buffer) and then, a
> notification is sent, which makes it possible to read all the values
> stored in the buffer using the notification signal handler.
>
Correct. Note that there is no partial samples, therefore the notification
may be sent before the kernel writes the last byte in the buffer. In fact,
notification is sent when:
bytes_left <= sizeof(sample_header)+8*max_num_pmds
On Montvale, max_num_pmds = 35.
> The number of notifications is the number of times the sampling buffer
> overflowed, isn't it? So why does it look limited to 31? I mean, even if
Yes, assuming your resume monitoring() via pfm_restart() at the end of
each notification.
> the buffer size is always rounded up to 16KB, the more collected events
> (because of a smaller sampling period or a higher number of iterations
> of our code, for example) the more often the buffer will become full and
> the more notifications we'll get, right? So why just a maximum of 31
> notifications? Cannot the buffer be reused infinite times?
>
> About extracting DEAR information without a sampling buffer, I defined a
> variable "pfarg_reg_t pd[NUM_PMDS]" as in the "notify_self.c" code.
> Then, in the sigio_handler() I try to make a cast to access the
> information of the pmd32, in this manner, but without success:
>
> pfm_mont_pmd_reg_t reg = (pfm_mont_pmd_reg_t)pd[0].reg_value;
> printf("PMD32: 0x%016lx\n", reg.pmd32_mont_reg.dear_daddr);
>
Did you read the pmds in the handler via pfm_read_pmds()?
> El mié, 13-05-2009 a las 08:42 +0200, stephane eranian escribió:
>> Juan,
>>
>> 2009/5/12 Juan Ángel Lorenzo <jalmailingli...@gmail.com>:
>> > Hi all,
>> >
>> > I've been doing some tests with the "mont_dear.c" example from the
>> > old_interface_ia64_examples directory and I've noticed a strange behaviour
>> > when sampling. I modified the ctx.buf_arg.buf_size variable from the
>> > initial
>> > value (getpagesize()) to the minimum value I was allowed (1024) and I tried
>> > the sampling periods 40 and 1. The aim of this was getting the maximum
>> > number of buffer overflow notifications. I considered that a lower sample
>> > period and a smaller buffer size would result in a higher number of
>> > overflow
>> > notifications. Everything worked as expected when using a sampling period
>> > of
>> > 40 and decreasing the buffer size. That is, the smaller the buffer, the
>> > smaller the number of samples per buffer and the higher the number of
>> > notifications, until I reached a 1024 buffer size, where I got 31
>> > notifications.
>> >
>> I believe what you are seeing can be explained by the rounding that is done
>> by the kernel. The kernel sampling buffer size must be a multiple of the page
>> size because it gets remapped. Mapping needs page granularity. On IA-64,
>> the default page size is 16KB. If you specify 1024, then it is rounded
>> up to 16KB.
>> That's problably why if you vary the size but remains within the
>> range, you get the
>> same number of notifications.
>>
>> > However, when using a sampling period of 1, regardless the buffer size, I
>> > always get a maximum number of notifications equals to 31. This value was
>> > double-checked using a global variable and getting the value of
>> > "hdr->hdr_overflows", in the "process_smpl_buffer()" function.
>> >
>> > I understand I'm not getting a real sampling period of 1 so I'll always
>> > miss
>> > some samples but, anyway, I don't see why I cannot get a higher number of
>> > notifications than 31. Subsequent tests with other codes, based in this
>> > example code, yiedled always that ceiling of 31 notifications.
>> >
>> > In order not to depend on the buffer I also tried to remove it, so that I
>> > got a notification every time the counter overflowed. As far as I read in
>> > the perfmon2 manual, it is possible to do it. Besides, there is an example
>> > code, "notify_self.c" which explains how to do it with "counting counters".
>> > I couldn't make it work with EARs, though. Is it possible to perform an EAR
>> > sampling without using a buffer? I'm working in a Montvale architecture
>> > (SuSE Enterprise 10 SP1, kernel 2.6.16.53).
>> >
>>
>> It is possible to extract DEAR information without a sampling buffer. In
>> the notification signal handler, you simply have to read the DEAR registers
>> (pmd32,pmd33,pmd36) before you resume monitoring.
>
>
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
