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
