From: MONTGOMERY,BOB (HP-FtCollins,ex1) <bob...@hp...> - 2002-03-14 18:47:14
Attachments:
patch-0.1-use_rtc.gz
|
> -----Original Message----- > From: John Levon [mailto:le...@mo...] > Sent: Thursday, March 14, 2002 10:19 AM > To: William Cohen > Cc: opr...@li... > Subject: Re: rtc mode vs. performance monitoring hardware mode > > > There is one distinct exception: oprofile profiling the effect of its > own interrupt handler. We intend to do some experiments with > this in the > future, but I can't imagine this code will ever get merged into > mainline. The rtc handler can never interrupt the NMI handler part of oprofile. The rtc handler can't profile any interesting interrupt handling code in the kernel. The NMI handler could profile the rtc handler, but ... ? > > Well it's trivial to force-set CPU_RTC in op_init.c. I guess > there's no > particular reason to not have a "force_rtc=1" module parameter. Fancy > making us a patch ? Attached is the one I use moved up to oprofile-0.1. I called it "use_rtc". Note that the rtc mode works badly on SMP systems. Each interrupt is processed by only one of the CPUs in a sort of haphazard way (it seems). I had this idea on how to fix that, but I ran into a stopper along the way: Schedule a tasklet from the rtc_interrupt handler. When the tasklet wakes up (it should still be on the same CPU that handled the RTC interrupt), it uses smp_call_function to run a pseudo-rtc handler function on the other CPUS. Since smp_call_function is implemented by interrupting the destination CPUs, they could record where they were interrupted, and you'd almost get a sample from every CPU for every RTC interrupt (I saw cases where the tasklet didn't run for absolutely every RTC interrupt). But... the function that is executed under interrupt on the other cpus as a result of smp_call_function does not get pt_regs as one of its parameters. So I couldn't figure out how to extract the sample address. Another afternoon shot :-) Bob M. |
From: MONTGOMERY,BOB (HP-FtCollins,ex1) <bob...@hp...> - 2002-03-14 20:51:55
Attachments:
patch-0.1-use_rtc.gz
|
> Thanks for the patch. What did you uses to compress it? I > assumed it was > a gzip file. That didn't work. I tried gzip, bunzip2, and unzip to > uncompress and none of them worked. Or did the file get > corrupted in the > email? Sorry, I corrupted it by ascii ftp'ing to a windows box on the way. Bob M. |
From: William C. <wc...@nc...> - 2002-03-14 19:35:56
|
Thanks for the patch. What did you uses to compress it? I assumed it was a gzip file. That didn't work. I tried gzip, bunzip2, and unzip to uncompress and none of them worked. Or did the file get corrupted in the email? -Will MONTGOMERY,BOB (HP-FtCollins,ex1) wrote: > >>-----Original Message----- >>From: John Levon [mailto:le...@mo...] >>Sent: Thursday, March 14, 2002 10:19 AM >>To: William Cohen >>Cc: opr...@li... >>Subject: Re: rtc mode vs. performance monitoring hardware mode >> >> >>There is one distinct exception: oprofile profiling the effect of its >>own interrupt handler. We intend to do some experiments with >>this in the >>future, but I can't imagine this code will ever get merged into >>mainline. >> > > The rtc handler can never interrupt the NMI handler part of oprofile. The > rtc handler can't profile any interesting interrupt handling code in the > kernel. The NMI handler could profile the rtc handler, but ... ? > > >>Well it's trivial to force-set CPU_RTC in op_init.c. I guess >>there's no >>particular reason to not have a "force_rtc=1" module parameter. Fancy >>making us a patch ? >> > > Attached is the one I use moved up to oprofile-0.1. I called it "use_rtc". > > Note that the rtc mode works badly on SMP systems. Each interrupt is > processed by only one of the CPUs in a sort of haphazard way (it seems). I > had this idea on how to fix that, but I ran into a stopper along the way: > Schedule a tasklet from the rtc_interrupt handler. When the tasklet wakes > up (it should still be on the same CPU that handled the RTC interrupt), it > uses smp_call_function to run a pseudo-rtc handler function on the other > CPUS. Since smp_call_function is implemented by interrupting the > destination CPUs, they could record where they were interrupted, and you'd > almost get a sample from every CPU for every RTC interrupt (I saw cases > where the tasklet didn't run for absolutely every RTC interrupt). But... > the function that is executed under interrupt on the other cpus as a result > of smp_call_function does not get pt_regs as one of its parameters. So I > couldn't figure out how to extract the sample address. Another afternoon > shot :-) > > Bob M. > > > > > patch-0.1-use_rtc.gz > > Content-Type: > > application/octet-stream > Content-Encoding: > > base64 > > |
From: John L. <le...@mo...> - 2002-03-14 21:21:15
|
On Thu, Mar 14, 2002 at 10:46:56AM -0800, MONTGOMERY,BOB (HP-FtCollins,ex1) wrote: > The rtc handler can never interrupt the NMI handler part of oprofile. The > rtc handler can't profile any interesting interrupt handling code in the > kernel. The NMI handler could profile the rtc handler, but ... ? Well exactly. At the least we'd need some check we're not in the rtc handler. It complicates and slows down the most critical path in the profiler ... > Note that the rtc mode works badly on SMP systems. Each interrupt is > processed by only one of the CPUs in a sort of haphazard way (it seems). I This is dependent on your system (in particular using noapic will make all interrupts go to CPU#0). The arbitration is supposed to distribute interrupts evenly across the CPUs, and that's what I found happened in my tests (well it's more complicated than that, but I didn't see your behaviour). > up (it should still be on the same CPU that handled the RTC interrupt), it > uses smp_call_function to run a pseudo-rtc handler function on the other This is really like greasing a tortoise IMHO. regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such. |