Yes, I was rather hoping this test case would cause a hang, because then I 
could send it off to the Power Linux maintainer ;-)

- Corey

"stephane eranian" <eran...@googlemail.com> wrote on 01/07/2009 12:03:24 
PM:

> Corey,
> 
> I was expecting success with the program below if /tmp/foo exists.
> 
> The perfmon code that handles all of this is generic, so there must be a
> race condition somewhere which is only exposed on Power.
> 
> On Wed, Jan 7, 2009 at 8:02 PM, Corey J Ashford <cjash...@us.ibm.com> 
wrote:
> > Thanks for the reply, Stephane.  I tried the test case you suggested:
> >
> > main() {
> >   int fd;
> >   void *addr;
> >
> >   fd = open ("/tmp/foo", O_RDONLY);
> >   printf("fd = %d\n", fd);
> >   addr = mmap(NULL, 10, PROT_READ, MAP_PRIVATE, fd, 0);
> >   printf("addr = %p\n", addr);
> >   if (close(fd)) {
> >      printf("close failed\n");
> >   }
> >   if (munmap(addr, 10)) {
> >      printf("munmap failed\n");
> >   }
> > }
> >
> > and it worked fine.  So apparently there is a problem related to
> > munmap'ing a perfmon fd on Power.  This will need more investigation,
> > obviously.
> >
> > - Corey
> >
> > "stephane eranian" <eran...@googlemail.com> wrote on 01/06/2009 
10:28:41
> > PM:
> >
> >> Corey,
> >>
> >> On Wed, Jan 7, 2009 at 3:24 AM, Corey J Ashford <cjash...@us.ibm.com>
> > wrote:
> >> >
> >> > Hello,
> >> >
> >> > I'd appreciate it if someone on this mailing list could try out the
> > libpfm
> >> > example: task_smpl and see if it runs correctly for you on any 
other
> >> > architecture besides Power.
> >> >
> >> > When I run it on my Power5-based machine here, I get a system hang
> > that
> >> > occurs when the munmap call is made.  Looking at the code in the
> > example, I
> >> > reversed the order of the close and munmap... so that the memory is
> > unmapped
> >> > before the fd is closed, and this allows the test to run to 
completion
> >> > without error and causes no hang.  I also tried commenting out the
> > call to
> >> > pfm_start, to cut  perfmon out of the loop for the most part, and 
the
> >> > behavior still reproduces - the system hangs unless I reverse those
> > two
> >> > calls.
> >> >
> >> > When the system hangs like this, if I get it to go into Xmon, none 
of
> > the
> >> > CPU stacks are interesting.  They all appear to be idle.
> >> >
> >> > I run the test as follows:
> >> >
> >> > ./task_smpl /bin/sleep 3
> >> >
> >>
> >> This test runs fine on my x86-64 system (Core 2). The order of the
> >> close() vs munmap()
> >> should not matter. The calls can be made in any order. The perfmon
> >> context is destroyed
> >> when the last reference to the file descriptor disappears, mmap 
counts
> >> as 1. If you do close()
> >> followed by munmap(), the perfmon context is destroyed as part of the
> >> munmap(). This sequence
> >> should not hang for you. What happens if you do a similar sequence 
but
> >> just with a regular file:
> >>     fd = open("/tmp/foo);
> >>     addr = mmap(fd);
> >>     close(fd);
> >>     munmap(addr);
> >>
> >> The test runs to completion on both x86-64 and ia64:
> >>
> >> $ task_smpl /bin/sleep 3
> >> sycall base 295
> >> major version 2
> >> minor version 82
> >> [FIXED_CTRL(pmc16)=0xaa pmi0=1 en0=0x2 pmi1=1 en1=0x2 pmi2=1 en2=0x0]
> >> INSTRUCTIONS_RETIRED UNHALTED_CORE_CYCLES
> >> [FIXED_CTR0(pmd16)]
> >> [FIXED_CTR1(pmd17)]
> >> programming 1 PMCS and 2 PMDS
> >> buffer mapped @0x7f999029b000
> >> hdr_cur_offs=128 version=1.0
> >> task terminated
> >> entry 0 PID:32691 TID:32691 CPU:2 LAST_VAL:100000 IIP:0x7f66702246c2
> >> PMD16 :0x0000000000004130
> >> entry 1 PID:32691 TID:32691 CPU:2 LAST_VAL:100213 IIP:0x7f6670227560
> >> PMD16 :0x000000000000ef70
> >> entry 2 PID:32691 TID:32691 CPU:2 LAST_VAL:100060 IIP:0x7f6670233e52
> >> PMD16 :0x000000000000f384
> >> entry 3 PID:32691 TID:32691 CPU:2 LAST_VAL:100155 
IIP:0xffffffff805c9e6f
> >> PMD16 :0x00000000000104fe
> >> 4 samples (4 in partial buffer) collected in 0 buffer overflows
> >> real 0h00m03.001s user 0h00m00.000s sys 0h00m00.001s
> >> $
> >
> >


------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to