perfctr-devel — Discussions about the development and use of the perfctr driver.

[Perfctr-devel] Ere cold as well as hungry, and toward mo

[Maslen <ja...@uk...>]

 run with the rest of the flock. He said, too, that if a turkey were
shut up in a well-lighted place, it would fret itself, running to and
fro, particularly if it heard other turkeys calling to it. The food for
fattening turkeys, said Tibbetts, should consist of a warm dough, made
from two parts corn meal and one part wheat bran. To a quart of such
dough he asserted that a tablespoonful of powdered eggshells should be
added, also a dust of Cayenne pepper. And if a really perfect food for
fattening poultry were desired, Tibbetts declared that a tablespoonful
of new rum should be added to the water with which the quart of dough
was mixed. A wonderful turkey food, no doubt! Tibbetts also told
Halstead to take a pair of sharp shears and cut off an inch and a half
of his turkey's "quitter," if it were too long and bothered him about
eating. If the turkey grew "dainty," as Tibbetts expressed it, Halstead
was to make the dough into rolls about the size of his thumb, then open
the bird's beak, s

[Perfctr-devel] Stool across the room.) ERNEST (addressing an imaginary audien

[Touton <gho...@bo...>]

Ity and screams.) LADY MARY (calling). Crichton, Crichton! (It must have
been TREHERNE who was tree-felling, for CRICHTON comes to her from the
hut, drawing his cutlass.) CRICHTON (anxious). Did you call, my lady?
LADY MARY (herself again, now that he is there). I! Why should I?
CRICHTON. I made a mistake, your ladyship. (Hesitating.) If you are
afraid of being alone, my lady-- LADY MARY. Afraid! Certainly not.
(Doggedly.) You may go. (But she does not complain when he remains
within eyesight cutting the bamboo. It is heavy work, and she watches
him silently.) LADY MARY. I wish, Crichton, you could work without
getting so hot. CRICHTON (mopping his face). I wish I could, my lady.
(He continues his labours.) LADY MARY (taking off her oilskins). It
makes me hot to look at you. CRICHTON. It almost makes me cool to look
at your ladyship. LADY MARY (who perhaps thinks he is presuming).
Anything I can do for you in that way, Crichton, I shall do with
pleasure. CRICHTON (quite humbly). Thank you, my lady. (By this time
most of the bamboo has been cut, and the shore and sea are visible,
except where they are hidden by the half completed hut. The mast rising
solitary from the water adds to the desolation of the scene, and at last
tears run down LADY MARY'S face.) CRICHTON. Don't give way, my lady,
things might be worse. LADY MARY. My poor father. CRICHTON. If I could
have given my life for his. LADY MARY. You did all a man could do.
Indeed I thank you, Crichton. (With some admiration and more wonder.)
You are a man. CRICHTON. Thank you, my lady. LADY MARY. But it is all so
awful. Crichton, is there any hope of a ship coming? CRICHTON (after
hesitation). Of course there is, my lady. LADY MARY (facing him
bravely). Don't treat me as a chi

Re: [Perfctr-devel] How to build Perfctr 32-bit libray on 64-bit AMD machine

[Mikael P. <mi...@it...>]

Muhammad aleem wrote:
> i have changed the make file accordingly (make fike in usr.lib) 
> it compiles and generated 32-bit lib also, but this lib is also not working with "collect" program
> Error message" HW counters not suported"

I have no idea if that indicates a problem in perfctr or in "collect"
(whatever that is). Ask whoever supplied "collect" to provide a decent
error message.

> my other question is that i also tried to use "perfex" but it does not list down performance events on my system
> My system Architecture
> 
> cat /proc/cpuinfo
> 
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 16
> model           : 2
> model name      : Quad-Core AMD Opteron(tm) Processor 8356
> stepping        : 3
> cpu MHz         : 1200.000
> cache size      : 512 KB
> physical id     : 0
> siblings        : 4
> . . . . 
> 
> ]$ perfex -l
> CPU type AMD Family 10h
> One time-stamp counter available
> 4 performance counters available
> Overflow interrupts available
> 
> Then i searched for  event list to for this CPU type is not available
> 
> Then i searched event list for this CPU type and found some event list 
> Basic Performance Measurements for AMD Athlon⢠64, AMD Opteron ...
> 
> but some events are working some are not 
> e.g.
> ]$ perfex -e 0x410000 /bin/ls
> java workspace 
> tsc                                         8372931
> event 0x00410000@0                                2
> 
> 
> ]$ perfex -e 0x80000 java matrix
> perfex: receiving fd/status: Operation not permitted

You failed to set the enable bit.

> i want to do L1,L2,L3 cache misses and memory bandwith counter values for my program, Can anybody guide me for these what event codes should i use?

If you need to ask that question, then you're using the wrong tool.
To use perfctr you must be familiar with the PMU programming details
of the processor in question.
If you want a higher-level user-friendly interface, use PAPI.

Re: [Perfctr-devel] How to build Perfctr 32-bit libray on 64-bit AMD machine

[Muhammad a. <al...@ya...>]

Dear Mikael,

i have changed the make file accordingly (make fike in usr.lib) 
it compiles and generated 32-bit lib also, but this lib is also not working with "collect" program
Error message" HW counters not suported"

Modified make file
 
# $Id: Makefile,v 1.26.2.42 2009/06/11 14:29:19 mikpe Exp $ 

SHELL=/bin/sh 
ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e 
s/arm.*/arm/ -e s/sa110/arm/) 
CC=gcc 
CFLAGS=-O2 -fomit-frame-pointer -Wall 
BUILD_INCLDIR=../linux/include 
CPPFLAGS=-I$(BUILD_INCLDIR) 
+LD=ld 
AR=ar 
ARFLAGS=ruv 
RANLIB=ranlib 

i386_ESOBJS=event_set_x86.o event_set_amd.o event_set_centaur.o\ 
  event_set_p4.o event_set_p5.o event_set_p6.o 
x86_64_ESOBJS=event_set_x86.o event_set_amd.o event_set_p4.o 
ppc_ESOBJS=event_set_ppc.o 
arm_ESOBJS=event_set_arm.o 
EVENT_SET_OBJS=$($(ARCH)_ESOBJS) 

i386_OBJS=x86.o 
x86_64_OBJS=x86.o 
ppc_OBJS=ppc.o 
arm_OBJS=arm.o 
ARCH_OBJS=$($(ARCH)_OBJS) 

i386_H=x86.h 
x86_64_H=x86.h 
ppc_H=ppc.h 
arm_H=arm.h 
ARCH_H=$($(ARCH)_H) 

AR_OBJS=global.o misc.o virtual.o marshal.o $(EVENT_SET_OBJS) $(ARCH_OBJS) 

SO_OBJS=$(AR_OBJS:.o=.os) 

# This is exceedingly ugly. 
i386_ABIVER=5 
x86_64_ABIVER=6 
ppc_ABIVER=5 
arm_ABIVER=0 
SO_ABIVER=$($(ARCH)_ABIVER) 

SO_LIBVER=2.6.39 
SO_NAME=libperfctr.so.$(SO_ABIVER) 
SO_LIB=libperfctr.so.$(SO_ABIVER).$(SO_LIBVER) 

HDEP=libperfctr.h $(BUILD_INCLDIR)/linux/perfctr.h 
$(BUILD_INCLDIR)/asm/perfctr.h 

i386_ASM_DIR=x86 
x86_64_ASM_DIR=x86 
ppc_ASM_DIR=powerpc 
arm_ASM_DIR=arm 
ARCH_ASM_DIR=asm-$($(ARCH)_ASM_DIR) 

INSTALL_FILES=$(BUILD_INCLDIR)/$(ARCH_ASM_DIR)/perfctr.h 
$(BUILD_INCLDIR)/linux/perfctr.h\ 
  libperfctr.h libperfctr.a libperfctr.so perfctr_event_codes.h 
CLEAN_FILES=$(AR_OBJS) $(SO_OBJS) libperfctr.a libperfctr.so 
gen-event-codes perfctr_event_codes.h marshal.c marshal.h libperfctr.o 

# Prevent 16-byte stack alignment crap in gcc-2.95. 
CFLAGS += $(shell if $(CC) -mpreferred-stack-boundary=2 -S -o /dev/null 
-x c /dev/null > /dev/null 2>&1; then echo 
"-mpreferred-stack-boundary=2"; fi) 

.SUFFIXES: .os 

%.os: %.c 
  $(COMPILE.c) -fPIC $(OUTPUT_OPTION) $< 

# this code does not need -fno-strict-aliasing 

default: $(INSTALL_FILES) libperfctr.o 

libperfctr.a:  $(AR_OBJS) 
  $(AR) $(ARFLAGS) libperfctr.a $(AR_OBJS) 
  $(RANLIB) libperfctr.a 

# not installed, only built as a workaround for PAPI's broken Makefiles 
libperfctr.o:  $(AR_OBJS) 
  $(LD) -r -o $@ $(AR_OBJS) 
libperfctr.so: $(SO_OBJS) 
  $(CC) -shared -o $@ -Wl,-soname,$(SO_NAME) $(SO_OBJS) 

$(AR_OBJS): $(HDEP) 
$(SO_OBJS): $(HDEP) 
$(EVENT_SET_OBJS):   event_set.h 

$(BUILD_INCLDIR)/asm/perfctr.h: 
  cd ..; make configure 

misc.o virtual.o global.o: marshal.h 
misc.o virtual.o: arch.h $(ARCH_H) 
marshal.o:  marshal.c marshal.h 
marshal.c: 
  ln -s ../linux/drivers/perfctr/marshal.c . 
marshal.h: 
  ln -s ../linux/drivers/perfctr/marshal.h . 

perfctr_event_codes.h:  gen-event-codes 
  ./gen-event-codes > $@ 

gen-event-codes:  gen-event-codes.c $(EVENT_SET_OBJS) 
  $(LINK.c) $^ -o $@ 

install: $(INSTALL_FILES) 
  -mkdir -p $(INCLDIR) $(INCLDIR)/asm $(INCLDIR)/linux 
  cp -f libperfctr.h $(INCLDIR)/ 
  cp perfctr_event_codes.h $(INCLDIR)/ 
  cp -f ../linux/include/$(ARCH_ASM_DIR)/perfctr.h $(INCLDIR)/asm/ 
  cp -f ../linux/include/linux/perfctr.h $(INCLDIR)/linux/ 
  -mkdir -p $(LIBDIR) 
  cp libperfctr.a $(LIBDIR)/ 
  cp libperfctr.so $(LIBDIR)/$(SO_LIB) 
  ln -sf $(SO_LIB) $(LIBDIR)/$(SO_NAME) 
  ln -sf $(SO_NAME) $(LIBDIR)/libperfctr.so 

distclean realclean: clean 

clean: 
  rm -f $(CLEAN_FILES) 


----------------------------------------------------------------------------

my other question is that i also tried to use "perfex" but it does not list down performance events on my system
My system Architecture

cat /proc/cpuinfo

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 2
model name      : Quad-Core AMD Opteron(tm) Processor 8356
stepping        : 3
cpu MHz         : 1200.000
cache size      : 512 KB
physical id     : 0
siblings        : 4
. . . . 

]$ perfex -l
CPU type AMD Family 10h
One time-stamp counter available
4 performance counters available
Overflow interrupts available

Then i searched for  event list to for this CPU type is not available

Then i searched event list for this CPU type and found some event list 
Basic Performance Measurements for AMD Athlon™ 64, AMD Opteron ...

but some events are working some are not 
e.g.
]$ perfex -e 0x410000 /bin/ls
java workspace 
tsc                                         8372931
event 0x00410000@0                                2


]$ perfex -e 0x80000 java matrix
perfex: receiving fd/status: Operation not permitted


i want to do L1,L2,L3 cache misses and memory bandwith counter values for my program, Can anybody guide me for these what event codes should i use?

Many Thanks.





________________________________
From: Mikael Pettersson <mi...@it...>
To: Muhammad aleem <al...@ya...>
Cc: per...@li...
Sent: Mon, November 2, 2009 12:30:24 PM
Subject: Re: [Perfctr-devel] How to build Perfctr 32-bit libray on 64-bit AMD machine

Muhammad aleem writes:
> Dear all,
> 
> I have downloaded perfctrl library (used by "collect" tool) as this is
> required by collect tool for getting performance data from underline
> system.
> from http://user.it.uu.se/~mikpe/linux/perfctr/2.6/perfctr-2.6.34.tar.gz
> 
> OS
> Linux MyMachine 2.6.18-92.el5.src-PAPI #1 SMP Tue Jan 27 10:57:40 CET 2009 x86_64 x86_64 x86_64 GNU/Linux
> 
> Architecture
> AMD 64 bits (Family 10h) or x86_64
> 
> I am using Java version
> $ java -version
> java version "1.6.0_10"
> Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
> 
> 
> My question is that when i install using defaults, perfctr user library
> installs 64-bit of libray version that can be used with 64-bit JVM
> but i need to use or get performance data using "collect" tool and
> 32-bit JVM, for that i think i need 32-bit version of "perfctr" library
> So i want to know can any body kindly tell me how to build 32-bit "perfctl" library on my system.

Apply the patch below (which fixes a non-critical build issue), then

make ARCH=i386 CC='gcc -m32' LD='ld -m elf_i386'

I tried just using 'setarch i386 make' but gcc kept generating 64-bit
object code, so 'gcc -m32' is apparently required.

--- perfctr-2.6.39/usr.lib/Makefile.~1~    2009-06-11 16:29:19.000000000 +0200
+++ perfctr-2.6.39/usr.lib/Makefile    2009-11-02 12:21:26.000000000 +0100
@@ -6,6 +6,7 @@ CC=gcc
CFLAGS=-O2 -fomit-frame-pointer -Wall
BUILD_INCLDIR=../linux/include
CPPFLAGS=-I$(BUILD_INCLDIR)
+LD=ld
AR=ar
ARFLAGS=ruv
RANLIB=ranlib
@@ -74,7 +75,7 @@ libperfctr.a:    $(AR_OBJS)

# not installed, only built as a workaround for PAPI's broken Makefiles
libperfctr.o:    $(AR_OBJS)
-    ld -r -o $@ $(AR_OBJS)
+    $(LD) -r -o $@ $(AR_OBJS)

libperfctr.so:    $(SO_OBJS)
    $(CC) -shared -o $@ -Wl,-soname,$(SO_NAME) $(SO_OBJS)



      

[Perfctr-devel] Offcore Response

[Dan T. <ter...@ee...>]

Mikael -

Does perfctr support the Offcore Response event (0xB7, unit mask 0x01) for
Nehalem?

It requires the use of a companion MSR_OFFCORE_RSP_0 register.

If so, how is that companion register set?

Thanks,

- dan

Re: [Perfctr-devel] How to build Perfctr 32-bit libray on 64-bit AMD machine

[Mikael P. <mi...@it...>]

Muhammad aleem writes:
 > Dear all,
 > 
 > I have downloaded perfctrl library (used by "collect" tool) as this is
 > required by collect tool for getting performance data from underline
 > system.
 > from http://user.it.uu.se/~mikpe/linux/perfctr/2.6/perfctr-2.6.34.tar.gz
 > 
 > OS
 > Linux MyMachine 2.6.18-92.el5.src-PAPI #1 SMP Tue Jan 27 10:57:40 CET 2009 x86_64 x86_64 x86_64 GNU/Linux
 > 
 > Architecture
 > AMD 64 bits (Family 10h) or x86_64
 > 
 > I am using Java version
 > $ java -version
 > java version "1.6.0_10"
 > Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
 > Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
 > 
 > 
 > My question is that when i install using defaults, perfctr user library
 > installs 64-bit of libray version that can be used with 64-bit JVM
 > but i need to use or get performance data using "collect" tool and
 > 32-bit JVM, for that i think i need 32-bit version of "perfctr" library
 > So i want to know can any body kindly tell me how to build 32-bit "perfctl" library on my system.

Apply the patch below (which fixes a non-critical build issue), then

make ARCH=i386 CC='gcc -m32' LD='ld -m elf_i386'

I tried just using 'setarch i386 make' but gcc kept generating 64-bit
object code, so 'gcc -m32' is apparently required.

--- perfctr-2.6.39/usr.lib/Makefile.~1~	2009-06-11 16:29:19.000000000 +0200
+++ perfctr-2.6.39/usr.lib/Makefile	2009-11-02 12:21:26.000000000 +0100
@@ -6,6 +6,7 @@ CC=gcc
 CFLAGS=-O2 -fomit-frame-pointer -Wall
 BUILD_INCLDIR=../linux/include
 CPPFLAGS=-I$(BUILD_INCLDIR)
+LD=ld
 AR=ar
 ARFLAGS=ruv
 RANLIB=ranlib
@@ -74,7 +75,7 @@ libperfctr.a:	$(AR_OBJS)
 
 # not installed, only built as a workaround for PAPI's broken Makefiles
 libperfctr.o:	$(AR_OBJS)
-	ld -r -o $@ $(AR_OBJS)
+	$(LD) -r -o $@ $(AR_OBJS)
 
 libperfctr.so:	$(SO_OBJS)
 	$(CC) -shared -o $@ -Wl,-soname,$(SO_NAME) $(SO_OBJS)

[Perfctr-devel] How to build Perfctr 32-bit libray on 64-bit AMD machine

[Muhammad a. <al...@ya...>]

Dear all,

I have downloaded perfctrl library (used by "collect" tool) as this is
required by collect tool for getting performance data from underline
system.
from http://user.it.uu.se/~mikpe/linux/perfctr/2.6/perfctr-2.6.34.tar.gz

OS
Linux MyMachine 2.6.18-92.el5.src-PAPI #1 SMP Tue Jan 27 10:57:40 CET 2009 x86_64 x86_64 x86_64 GNU/Linux

Architecture
AMD 64 bits (Family 10h) or x86_64

I am using Java version
$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)


My question is that when i install using defaults, perfctr user library
installs 64-bit of libray version that can be used with 64-bit JVM
but i need to use or get performance data using "collect" tool and
32-bit JVM, for that i think i need 32-bit version of "perfctr" library
So i want to know can any body kindly tell me how to build 32-bit "perfctl" library on my system.


Many Thanks    


      

Re: [Perfctr-devel] Perctr for newest kernels?

[Ingo M. <mi...@el...>]

* Philip Mucci <mu...@ee...> wrote:

>
> On Oct 16, 2009, at 3:31 PM, William Cohen wrote:
>
>> Dan Terpstra wrote:
>>> I thought it was pretty obscene, too.
>>> We have a papi_cost utility that we routinely use to measure latency 
>>> on
>>> starts, stops, reads, etc. It performs a million pairs of reads of  
>>> two
>>> counters and reports min, max, mean and std. dev.
>>> I'm not intimately familiar with the implementation of the read  
>>> function in
>>> PAPI for this case. Suffice it to say that it's a first pass naïve
>>> implementation and could probably be optimized. But I'd be surprised 
>>> to see
>>> a factor of 10.
>>> - d
>>
>> I have a hacked version of valgrind for Fedora rawhide (*) that:
>>
>> 1) understands the basic sys_perf_event_open
>> 2) uses the native cpuid results rather than the valgrind synthetic  
>> cpuid
>>
>> I was able to run the papi_cost test with callgrind to get some call  
>> graph
>> information:
>>
>> valgrind --tool=callgrind  papi_cost
>>
>> The valgrind instrumentation messes up the timing, but the resulting
>> callgrind.out file can be analyzed with kcachegrind to see what  
>> functions are
>> being called from where. sys_perf_counter_open is being called a huge 
>> number of
>> times; from PAPI_reset. PAPI_accum is built on PAPI_reset.
>>
>
> I'm not sure why we are re-opening the counters in PAPI_reset, that's 
> either an error in the substrate or there's no clean way to reset the 
> counters, which I highly doubt. It's probably just an artifact of an 
> early implementation of PAPI over PCL, possible reset didn't exist 
> then. Let's ask Corey. Corey?

There's a reset ioctl:

 #define PERF_EVENT_IOC_RESET            _IO ('$', 3)

but anything that tries to measure the cost of reading a counter 
shouldnt even call an ioctl - it should just read the counter 
successively.

	Ingo

Re: [Perfctr-devel] Perctr for newest kernels?

[William C. <wc...@nc...>]

Dan Terpstra wrote:
> I thought it was pretty obscene, too. 
> We have a papi_cost utility that we routinely use to measure latency on
> starts, stops, reads, etc. It performs a million pairs of reads of two
> counters and reports min, max, mean and std. dev.
> I'm not intimately familiar with the implementation of the read function in
> PAPI for this case. Suffice it to say that it's a first pass naïve
> implementation and could probably be optimized. But I'd be surprised to see
> a factor of 10.
> - d

I have a hacked version of valgrind for Fedora rawhide (*) that:

1) understands the basic sys_perf_event_open
2) uses the native cpuid results rather than the valgrind synthetic cpuid

I was able to run the papi_cost test with callgrind to get some call graph
information:

valgrind --tool=callgrind  papi_cost

The valgrind instrumentation messes up the timing, but the resulting
callgrind.out file can be analyzed with kcachegrind to see what functions are
being called from where. sys_perf_counter_open is being called a huge number of
times; from PAPI_reset. PAPI_accum is built on PAPI_reset.

-Will


(*) http://people.redhat.com/wcohen/papi/valgrind-3.5.0-3.papi.src.rpm

>> -----Original Message-----
>> From: Ingo Molnar [mailto:mi...@el...]
>> Sent: Friday, October 16, 2009 5:02 AM
>> To: Dan Terpstra
>> Cc: 'Philip Mucci'; 'Peter Zijlstra'; per...@li...
>> Subject: Re: [Perfctr-devel] Perctr for newest kernels?
>>
>>
>> * Dan Terpstra <ter...@ee...> wrote:
>>
>>>>> There's no library for this yet - it's waiting for interested
>> parties
>>>>> with a strong need to squeeze out every cycle from the read-counters
>>>>> overhead.
>>>> Sounds like me.
>>>>
>>>> What would the library have to encapsulate? Do you giving it a call
>>>> interface similar to the existing read methods in perf_counters?
>>>>
>>>>> There are other non-syscall models of getting to the counts as well,
>>>>> depending on what the specific application is.
>>>> I wouldn't have much of a problem of doing the read outside PAPI.
>>>>
>>>> But I would really like to keep PAPI for setting things up.
>>> And PAPI would really like a library call that preserved the full 64
>>> bit range of a virtual counter with the speeds of perfctr access. BTW,
>>> as reported on the PAPI Forum, a PAPI/perfctr read of 2 counters costs
>>> ~137 cycles vs ~5600 cycles with PAPI/perf_count...er...perf_events.
>>> This is on a Nehalem with 2.6.31.
>> I dont know what PAPI does there really - 5600 cycles sounds obscene.
>>
>> Reading the counter is a single read() - which takes 255 cycles on a
>> Nehalem. (510 cycles if you use two separate fds)
>>
>> How was this measured?
>>
>> 	Ingo
>>
>> --------------------------------------------------------------------------
>> ----
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Perfctr-devel mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perfctr-devel
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Perfctr-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perfctr-devel
> 

Re: [Perfctr-devel] Perctr for newest kernels?

[Philip M. <mu...@ee...>]

On Oct 16, 2009, at 3:31 PM, William Cohen wrote:

> Dan Terpstra wrote:
>> I thought it was pretty obscene, too.
>> We have a papi_cost utility that we routinely use to measure  
>> latency on
>> starts, stops, reads, etc. It performs a million pairs of reads of  
>> two
>> counters and reports min, max, mean and std. dev.
>> I'm not intimately familiar with the implementation of the read  
>> function in
>> PAPI for this case. Suffice it to say that it's a first pass naïve
>> implementation and could probably be optimized. But I'd be  
>> surprised to see
>> a factor of 10.
>> - d
>
> I have a hacked version of valgrind for Fedora rawhide (*) that:
>
> 1) understands the basic sys_perf_event_open
> 2) uses the native cpuid results rather than the valgrind synthetic  
> cpuid
>
> I was able to run the papi_cost test with callgrind to get some call  
> graph
> information:
>
> valgrind --tool=callgrind  papi_cost
>
> The valgrind instrumentation messes up the timing, but the resulting
> callgrind.out file can be analyzed with kcachegrind to see what  
> functions are
> being called from where. sys_perf_counter_open is being called a  
> huge number of
> times; from PAPI_reset. PAPI_accum is built on PAPI_reset.
>

I'm not sure why we are re-opening the counters in PAPI_reset, that's  
either an error in the substrate or there's no clean way to reset the  
counters, which I highly doubt. It's probably just an artifact of an  
early implementation of PAPI over PCL, possible reset didn't exist  
then. Let's ask Corey. Corey?

One of the issues with papi_cost is that it doesn't have any modal  
options, i.e. it benchmarks everything and spits it out, which makes  
it hard for profiling. Would be real nice to get straight to the beef:  
papi_cost --read

Fortunately, nothing except papiex uses PAPI_accum. (It's only for  
sticking at the end of loop bodies for instrumentation systems that  
don't have the ability to instrument a loop epilog, like Pathscale's.)

Phil

> -Will
>
>
> (*) http://people.redhat.com/wcohen/papi/valgrind-3.5.0-3.papi.src.rpm
>
>>> -----Original Message-----
>>> From: Ingo Molnar [mailto:mi...@el...]
>>> Sent: Friday, October 16, 2009 5:02 AM
>>> To: Dan Terpstra
>>> Cc: 'Philip Mucci'; 'Peter Zijlstra'; per...@li...
>>> Subject: Re: [Perfctr-devel] Perctr for newest kernels?
>>>
>>>
>>> * Dan Terpstra <ter...@ee...> wrote:
>>>
>>>>>> There's no library for this yet - it's waiting for interested
>>> parties
>>>>>> with a strong need to squeeze out every cycle from the read- 
>>>>>> counters
>>>>>> overhead.
>>>>> Sounds like me.
>>>>>
>>>>> What would the library have to encapsulate? Do you giving it a  
>>>>> call
>>>>> interface similar to the existing read methods in perf_counters?
>>>>>
>>>>>> There are other non-syscall models of getting to the counts as  
>>>>>> well,
>>>>>> depending on what the specific application is.
>>>>> I wouldn't have much of a problem of doing the read outside PAPI.
>>>>>
>>>>> But I would really like to keep PAPI for setting things up.
>>>> And PAPI would really like a library call that preserved the full  
>>>> 64
>>>> bit range of a virtual counter with the speeds of perfctr access.  
>>>> BTW,
>>>> as reported on the PAPI Forum, a PAPI/perfctr read of 2 counters  
>>>> costs
>>>> ~137 cycles vs ~5600 cycles with PAPI/ 
>>>> perf_count...er...perf_events.
>>>> This is on a Nehalem with 2.6.31.
>>> I dont know what PAPI does there really - 5600 cycles sounds  
>>> obscene.
>>>
>>> Reading the counter is a single read() - which takes 255 cycles on a
>>> Nehalem. (510 cycles if you use two separate fds)
>>>
>>> How was this measured?
>>>
>>> 	Ingo
>>>
>>> --------------------------------------------------------------------------
>>> ----
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year.  
>>> Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market  
>>> and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register  
>>> now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Perfctr-devel mailing list
>>> Per...@li...
>>> https://lists.sourceforge.net/lists/listinfo/perfctr-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market  
>> and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Perfctr-devel mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perfctr-devel
>>
>

Re: [Perfctr-devel] Perctr for newest kernels?

[Dan T. <ter...@ee...>]

I thought it was pretty obscene, too. 
We have a papi_cost utility that we routinely use to measure latency on
starts, stops, reads, etc. It performs a million pairs of reads of two
counters and reports min, max, mean and std. dev.
I'm not intimately familiar with the implementation of the read function in
PAPI for this case. Suffice it to say that it's a first pass naïve
implementation and could probably be optimized. But I'd be surprised to see
a factor of 10.
- d

> -----Original Message-----
> From: Ingo Molnar [mailto:mi...@el...]
> Sent: Friday, October 16, 2009 5:02 AM
> To: Dan Terpstra
> Cc: 'Philip Mucci'; 'Peter Zijlstra'; per...@li...
> Subject: Re: [Perfctr-devel] Perctr for newest kernels?
> 
> 
> * Dan Terpstra <ter...@ee...> wrote:
> 
> > > >
> > > > There's no library for this yet - it's waiting for interested
> parties
> > > > with a strong need to squeeze out every cycle from the read-counters
> > > > overhead.
> > >
> > > Sounds like me.
> > >
> > > What would the library have to encapsulate? Do you giving it a call
> > > interface similar to the existing read methods in perf_counters?
> > >
> > > > There are other non-syscall models of getting to the counts as well,
> > > > depending on what the specific application is.
> > >
> > > I wouldn't have much of a problem of doing the read outside PAPI.
> > >
> > > But I would really like to keep PAPI for setting things up.
> >
> > And PAPI would really like a library call that preserved the full 64
> > bit range of a virtual counter with the speeds of perfctr access. BTW,
> > as reported on the PAPI Forum, a PAPI/perfctr read of 2 counters costs
> > ~137 cycles vs ~5600 cycles with PAPI/perf_count...er...perf_events.
> > This is on a Nehalem with 2.6.31.
> 
> I dont know what PAPI does there really - 5600 cycles sounds obscene.
> 
> Reading the counter is a single read() - which takes 255 cycles on a
> Nehalem. (510 cycles if you use two separate fds)
> 
> How was this measured?
> 
> 	Ingo
> 
> --------------------------------------------------------------------------
> ----
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Perfctr-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perfctr-devel

Re: [Perfctr-devel] Perctr for newest kernels?

[Ingo M. <mi...@el...>]

* Dan Terpstra <ter...@ee...> wrote:

> > >
> > > There's no library for this yet - it's waiting for interested parties
> > > with a strong need to squeeze out every cycle from the read-counters
> > > overhead.
> > 
> > Sounds like me.
> > 
> > What would the library have to encapsulate? Do you giving it a call
> > interface similar to the existing read methods in perf_counters?
> > 
> > > There are other non-syscall models of getting to the counts as well,
> > > depending on what the specific application is.
> > 
> > I wouldn't have much of a problem of doing the read outside PAPI.
> > 
> > But I would really like to keep PAPI for setting things up.
>
> And PAPI would really like a library call that preserved the full 64 
> bit range of a virtual counter with the speeds of perfctr access. BTW, 
> as reported on the PAPI Forum, a PAPI/perfctr read of 2 counters costs 
> ~137 cycles vs ~5600 cycles with PAPI/perf_count...er...perf_events. 
> This is on a Nehalem with 2.6.31.

I dont know what PAPI does there really - 5600 cycles sounds obscene.

Reading the counter is a single read() - which takes 255 cycles on a 
Nehalem. (510 cycles if you use two separate fds)

How was this measured?

	Ingo

Re: [Perfctr-devel] Perctr for newest kernels?

[Dan T. <ter...@ee...>]

> >
> > There's no library for this yet - it's waiting for interested parties
> > with a strong need to squeeze out every cycle from the read-counters
> > overhead.
> 
> Sounds like me.
> 
> What would the library have to encapsulate? Do you giving it a call
> interface similar to the existing read methods in perf_counters?
> 
> > There are other non-syscall models of getting to the counts as well,
> > depending on what the specific application is.
> 
> I wouldn't have much of a problem of doing the read outside PAPI.
> 
> But I would really like to keep PAPI for setting things up.
>
And PAPI would really like a library call that preserved the full 64 bit
range of a virtual counter with the speeds of perfctr access. BTW, as
reported on the PAPI Forum, a PAPI/perfctr read of 2 counters costs ~137
cycles vs ~5600 cycles with PAPI/perf_count...er...perf_events. This is on a
Nehalem with 2.6.31.
- d

Re: [Perfctr-devel] Perctr for newest kernels?

[Martin C. <cra...@co...>]

Ingo Molnar wrote on Wed, Oct 14, 2009 at 08:25:34PM +0200: 
> 
> </lurker mode>
> 
> * Philip Mucci <mu...@ee...> wrote:
> 
> > Hi Martin,
> > 
> > perf_counters won't be much faster than perfmon I'm afraid. You're 
> > stuck doing a read() syscall. It does provide for mmap'd operation on 
> > some processors like perfctr, but this is still not widely supported.
> 
> Martin, what CPU are you using?

Something that is i7 only would be fine for me.  I did most work on Core2.

> With performance events subsystem (it got renamed to that from 
> perfcounters) it's possible to use the RDPMC instruction directly and 
> avoid a system call overhead.
> 
> There's no library for this yet - it's waiting for interested parties 
> with a strong need to squeeze out every cycle from the read-counters 
> overhead.

Sounds like me.

What would the library have to encapsulate? Do you giving it a call
interface similar to the existing read methods in perf_counters?

> There are other non-syscall models of getting to the counts as well, 
> depending on what the specific application is.

I wouldn't have much of a problem of doing the read outside PAPI.

But I would really like to keep PAPI for setting things up.  I wrote
an extensive interface layer to Common Lisp that does all the strings
to symbols conversion and basically interfaces PAPI with the Lisp REPL
(aka commandline).  There's a lot of hair in there.

> > If you abandon PAPI and go directly to the substrate, you'll likely 
> > save a few hundred cycles, but that pales in comparison to the cost of 
> > a kernel boundary crossing (trap) that PCL does.
> 
> At least on x86 the cost of a full system call is ~110 cycles - or ~40 
> nsecs on a ~3GHz CPU. Depending on how fast your CPU is it should still 
> be below 100 nsecs.
> 
> Far from a 'few hundred cycles', let alone thousands of cycles.

I can tell you that for the context in question the time equivalent of
gettimeofday (35 ns on Core2@3GHz) is OK but read (500 ns) is not.

Unfortunately I didn't keep the times for perfctr and perfmon2, but
perfctr was quicker than gettimeofday (older Linux kernel with slower
gettimeofday, I think that was around 130ns), and perfmon2 was in
read(2) regions.

The application had these hooks put in for gettimeofday() usage and
has been hand-tuned to have acceptable overhead with that.  If I use
something that takes up 10x cycles I instantly drive it into
inacceptable overhead.

> > If you compile without PCL you should very easily be able to adapt a 
> > 2.6.28 perfctr patch to those kernels...
> 
> That's certainly true - perfctr is well isolated and does not depend on 
> many external entities. So if you are happy with it there's little 
> reason to switch.

I only occasionally use performance counters, basically to check
nothing really stupid sneaked into our codebase.  Since I sent the
mail I've been pointed to what you say, somebody provided a patch for
2.6.31 which presumably foreports to 2.6.31.3 easily.

But my use of performance counters doesn't warrant maintaining a patch
to a patch on my own.  Also, if I can re-base to perf_counters I will
be able to do the analysis on any machine in the office with a new
enough kernel.  I wouldn't have to continue to hijack machines to
install my own patched kernel on.

I'd rather do whatever it takes to use RDPMC with PAPI on top of
perf_counters than patch-patch perfctr, but I have to sty within those
-say- 100 nsecs on 3 GHz.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cra...@co...>   http://www.cons.org/cracauer/

Re: [Perfctr-devel] Perctr for newest kernels?

[Peter Z. <a.p...@ch...>]

On Wed, 2009-10-14 at 20:25 +0200, Ingo Molnar wrote:
> With performance events subsystem (it got renamed to that from 
> perfcounters) it's possible to use the RDPMC instruction directly and 
> avoid a system call overhead.

We need to sort out the index issue for fixed purpose counters and
actually enable the rdpmc instruction for ring3.

But yeah, it shouldn't be too hard to make that happen.

Re: [Perfctr-devel] Perctr for newest kernels?

[Ingo M. <mi...@el...>]

* Peter Zijlstra <a.p...@ch...> wrote:

> On Wed, 2009-10-14 at 20:25 +0200, Ingo Molnar wrote:
> > With performance events subsystem (it got renamed to that from 
> > perfcounters) it's possible to use the RDPMC instruction directly and 
> > avoid a system call overhead.
> 
> We need to sort out the index issue for fixed purpose counters and 
> actually enable the rdpmc instruction for ring3.
> 
> But yeah, it shouldn't be too hard to make that happen.

and we probably also want to provide a small library to make it easy for 
apps to make use of this facility.

So what it needs are folks interested in coding and testing it.

	Ingo

Re: [Perfctr-devel] Perctr for newest kernels?

[Ingo M. <mi...@el...>]

</lurker mode>

* Philip Mucci <mu...@ee...> wrote:

> Hi Martin,
> 
> perf_counters won't be much faster than perfmon I'm afraid. You're 
> stuck doing a read() syscall. It does provide for mmap'd operation on 
> some processors like perfctr, but this is still not widely supported.

Martin, what CPU are you using?

With performance events subsystem (it got renamed to that from 
perfcounters) it's possible to use the RDPMC instruction directly and 
avoid a system call overhead.

There's no library for this yet - it's waiting for interested parties 
with a strong need to squeeze out every cycle from the read-counters 
overhead.

There are other non-syscall models of getting to the counts as well, 
depending on what the specific application is.

> If you abandon PAPI and go directly to the substrate, you'll likely 
> save a few hundred cycles, but that pales in comparison to the cost of 
> a kernel boundary crossing (trap) that PCL does.

At least on x86 the cost of a full system call is ~110 cycles - or ~40 
nsecs on a ~3GHz CPU. Depending on how fast your CPU is it should still 
be below 100 nsecs.

Far from a 'few hundred cycles', let alone thousands of cycles.

> If you compile without PCL you should very easily be able to adapt a 
> 2.6.28 perfctr patch to those kernels...

That's certainly true - perfctr is well isolated and does not depend on 
many external entities. So if you are happy with it there's little 
reason to switch.

<lurker mode>

	Ingo

Re: [Perfctr-devel] Perctr for newest kernels?

[Mikael P. <mi...@it...>]

Martin Cracauer writes:
 > What are the expectations to port perfctr to newest Linux kernels?
 > 
 > Bugs in 2.6.29/30 and early 2.6.31s force me to go directly to
 > 2.6.31.3.  I have an application that does extensive self-monitoring
 > via PAPI and so far I used perfctr because perfmon was just too slow
 > at quickly reading counters, which I do very frequently.  I need
 > something that is about the speed of gettimeofday(2).
 > 
 > According to a question I posted on the PAPI forum they sit on top
 > Linux' new perf_counters only with an experimental implementation, and
 > they only interfaces PAPI to the slower methods of getting counters in
 > perf_counters (whatever that might be).  I have not benchmarked how
 > slow exactly that would be but I'm not optimistic.
 > 
 > In a word, I have a real need for perfctr on 2.6.31.3.

1. download perfctr-2.6.39.tar.gz
2. download patch-kernel-2.6.31 from the same location
3. unpack perfctr-2.6.39.tar.gz and move patch-kernel-2.6.31
   into its patches/ directory
4. update your 2.6.31.3 kernel as usual, invoking perfctr's
   update-kernel with "-p 2.6.31"

Re: [Perfctr-devel] Perctr for newest kernels?

[Philip M. <mu...@ee...>]

Hi Martin,

perf_counters won't be much faster than perfmon I'm afraid. You're  
stuck doing a read() syscall. It does provide for mmap'd operation on  
some processors like perfctr, but this is still not widely supported.

If you abandon PAPI and go directly to the substrate, you'll likely  
save a few hundred cycles, but that pales in comparison to the cost of  
a kernel boundary crossing (trap) that PCL does.

If you compile without PCL you should very easily be able to adapt a  
2.6.28 perfctr patch to those kernels...

Phil

On Oct 14, 2009, at 12:12 PM, Martin Cracauer wrote:

> What are the expectations to port perfctr to newest Linux kernels?
>
> Bugs in 2.6.29/30 and early 2.6.31s force me to go directly to
> 2.6.31.3.  I have an application that does extensive self-monitoring
> via PAPI and so far I used perfctr because perfmon was just too slow
> at quickly reading counters, which I do very frequently.  I need
> something that is about the speed of gettimeofday(2).
>
> According to a question I posted on the PAPI forum they sit on top
> Linux' new perf_counters only with an experimental implementation, and
> they only interfaces PAPI to the slower methods of getting counters in
> perf_counters (whatever that might be).  I have not benchmarked how
> slow exactly that would be but I'm not optimistic.
>
> In a word, I have a real need for perfctr on 2.6.31.3.
>
> Otherwise I would have to make a decision to maybe abandon PAPI and
> sit directly on top of perf_counters, which I would hate doing, or sit
> around doing nothing until the situation with PAPI on top of
> perf_counters gets sorted, which isn't my style.  And who knows what
> kind of (non-)pressure there is to support the faster calls.
>
> Looking for general comments.  What do you perfcrt users do now that
> some dices have been thrown?
>
> Martin
> -- 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> Martin Cracauer <cra...@co...>   http://www.cons.org/cracauer/
> FreeBSD - where you want to go, today.      http://www.freebsd.org/
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Perfctr-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perfctr-devel

[Perfctr-devel] Perctr for newest kernels?

[Martin C. <cra...@co...>]

What are the expectations to port perfctr to newest Linux kernels?

Bugs in 2.6.29/30 and early 2.6.31s force me to go directly to
2.6.31.3.  I have an application that does extensive self-monitoring
via PAPI and so far I used perfctr because perfmon was just too slow
at quickly reading counters, which I do very frequently.  I need
something that is about the speed of gettimeofday(2).

According to a question I posted on the PAPI forum they sit on top
Linux' new perf_counters only with an experimental implementation, and
they only interfaces PAPI to the slower methods of getting counters in
perf_counters (whatever that might be).  I have not benchmarked how
slow exactly that would be but I'm not optimistic.

In a word, I have a real need for perfctr on 2.6.31.3.

Otherwise I would have to make a decision to maybe abandon PAPI and
sit directly on top of perf_counters, which I would hate doing, or sit
around doing nothing until the situation with PAPI on top of
perf_counters gets sorted, which isn't my style.  And who knows what
kind of (non-)pressure there is to support the faster calls.

Looking for general comments.  What do you perfcrt users do now that
some dices have been thrown?

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cra...@co...>   http://www.cons.org/cracauer/
FreeBSD - where you want to go, today.      http://www.freebsd.org/

[Perfctr-devel] AUTO: Corey J Ashford is out of the office. (returning 10/12/2009)

[Corey J A. <cja...@us...>]

I am out of the office until 10/12/2009.

I will respond to your message when I return.


Note: This is an automated response to your message  "Perfctr-devel Digest,
Vol 38, Issue 1" sent on 10/11/09 19:20:00.

This is the only notification you will receive while this person is away.

Re: [Perfctr-devel] [Ptools-perfapi] kernel locking up while using overflow signals onMT code

[Yukon M. <Yuk...@Su...>]

On 09/24/09 14:16, Dan Terpstra wrote:
> Yukon -
> Does the Analyzer use PAPI or is this specifically a perfctr problem? 
Thanks Dan, this is specifically a perfctr issue.

Thank you for cross-posting to the correct list.  I have attached the 
test case.

Yukon


> If
> perfctr, you may benefit from cross posting on perfctr-devel.
> - dan
>
>   
>> -----Original Message-----
>> From: pto...@ee... [mailto:ptools-perfapi-
>> bo...@ee...] On Behalf Of Yukon Maruyama
>> Sent: Thursday, September 24, 2009 3:30 PM
>> To: pto...@ee...
>> Subject: [Ptools-perfapi] kernel locking up while using overflow signals
>> onMT code
>>
>> Perfapi folks,
>>
>> I work on Sun's Analyzer which uses perfctr on Linux.
>>
>> A user of the Analyzer is running into Linux hangs when enabling perfctr
>> for self-overflow-profiling. His code is MT (maybe 16 threads) each
>> which periodically calls swapcontext().  He's using a reasonable
>> overflow interval.
>>
>> I was able to reproduce a similar looking lockup on my system by using
>> two threads.
>> Each thread does some calculations and periodically calls sched_yield().
>> - If I use a high overflow rate, I get occasional OS hangs.
>> - If I use a very high overflow rate, the OS hangs consistently.
>> - But when I run only a single pthread instead of two, or if I run two
>> threads
>> but don't call sched_yield(), I don't see the problem, even at very
>> high profiling rates.
>>
>> My linux is:
>> Linux debroglie 2.6.18-128.1.10.el5_sunhpc1 #1 SMP Tue May 26 18:51:51
>> EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
>>
>> My processor is...
>> processor       : 0
>> vendor_id       : GenuineIntel
>> cpu family      : 6
>> model           : 15
>> model name      : Intel(R) Core(TM)2 Extreme CPU Q6850  @ 3.00GHz
>> stepping        : 11
>> cpu MHz         : 2999.666
>> cache size      : 4096 KB
>> physical id     : 0
>> siblings        : 4
>> core id         : 0
>> cpu cores       : 4
>> ...
>>
>> Hopefully someone can help us get to the bottom of this.  Thanks,
>>
>> Yukon
>>
>>     
>
>
>   

Re: [Perfctr-devel] [Ptools-perfapi] kernel locking up while using overflow signals onMT code

[Dan T. <ter...@ee...>]

Yukon -
Does the Analyzer use PAPI or is this specifically a perfctr problem? If
perfctr, you may benefit from cross posting on perfctr-devel.
- dan

> -----Original Message-----
> From: pto...@ee... [mailto:ptools-perfapi-
> bo...@ee...] On Behalf Of Yukon Maruyama
> Sent: Thursday, September 24, 2009 3:30 PM
> To: pto...@ee...
> Subject: [Ptools-perfapi] kernel locking up while using overflow signals
> onMT code
> 
> Perfapi folks,
> 
> I work on Sun's Analyzer which uses perfctr on Linux.
> 
> A user of the Analyzer is running into Linux hangs when enabling perfctr
> for self-overflow-profiling. His code is MT (maybe 16 threads) each
> which periodically calls swapcontext().  He's using a reasonable
> overflow interval.
> 
> I was able to reproduce a similar looking lockup on my system by using
> two threads.
> Each thread does some calculations and periodically calls sched_yield().
> - If I use a high overflow rate, I get occasional OS hangs.
> - If I use a very high overflow rate, the OS hangs consistently.
> - But when I run only a single pthread instead of two, or if I run two
> threads
> but don't call sched_yield(), I don't see the problem, even at very
> high profiling rates.
> 
> My linux is:
> Linux debroglie 2.6.18-128.1.10.el5_sunhpc1 #1 SMP Tue May 26 18:51:51
> EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
> 
> My processor is...
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Core(TM)2 Extreme CPU Q6850  @ 3.00GHz
> stepping        : 11
> cpu MHz         : 2999.666
> cache size      : 4096 KB
> physical id     : 0
> siblings        : 4
> core id         : 0
> cpu cores       : 4
> ...
> 
> Hopefully someone can help us get to the bottom of this.  Thanks,
> 
> Yukon
> 

[Perfctr-devel] website design service

[Johnny <sta...@ya...>]

You are receiving this email because we wish you to use our web design service. 

We are web design studio from China. We are specialized in web page design, website development, graphics & multi-media design, flash website design and other relevant services. We pride ourselves with our technical strength, professional vision, unique style, and most of all, our highly devoted professional designers. We are in position to offer website solution, graphics design, e-commerce solution, online promotion and other medium and small business oriented services. 

We have well experienced professionals in many Web platforms Such as Flash designs , Flash Action Scripts , DNN Skinning, PHP,ASP.Net, Flash , HTML , Photoshop, Web designs , Java scripts, Portal developments MY SQL, MS SQL etc ... Our technical, design and development team have grown in size to ensure we can continue providing excellent service to all of our customers. 

Core offerings

Business website design 
Business website redesign 
Flash website design 
Flash website redesign 
Ecommerce website design 
Ecommerce website redesign 
Company website design
Company catalog design
Company logo design
Graphic design
SEO service
ERP Solutions

Pls check our website to see portfolio. 


Best regards,
Johnny
Johnnythanme Information Technologies
Website Team
Contact: ibj...@ye...








Send address to web...@ye... for remove

                                                                                                                                                                 

[Perfctr-devel] nd bolted. Mi

[Dreggs <tu...@ge...>]

Day. It was sent from Carter's well-known drug store, and was to the
effect that a lady had just sent a boy in from the street to say that a
strange crime had been committed in ----'s mansion round the corner. The
boy did not know the lady, and was shy about showing the money she had
given him, but that he had money was very evident, also, that he was
frightened enough for his story to be true. If the police wished to
communicate with him, he could be found at Carter's, where he would be
detained till an order for his release should be received. A _strange_
crime! That word "strange" struck Mr. Gryce, and made him forget his
years in wondering what it meant. Meanwhile the men about him exchanged
remarks upon the house brought thus unexpectedly to their notice. As it
was one of the few remaining landmarks of the preceding century, and had
been made conspicuous moreover by the shops, club-houses, and
restaurants pressing against it on either side, it had been a marked
spot for years even t