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
(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.
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
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);
Thanks in advance for your time
Juan
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
