From: Don Z. <dz...@gm...> - 2006-04-10 18:22:15
|
> > I reworked this patch a little bit. This time I added a hack to _not_ > > expose performance counters (avail_to_resrv_perfctr_nmi() ) through > > the /dev/oprofile interface if they are reserved. Its an ugly hack > > but that is the result of the way oprofile was designed. There was > > also a bunch of other cleanups too but more related to nmi.c. > > > I think it looks okay. As Will pointed out, I think there is still > a problem with HyperThreading (HT). The counters are ALL Shared in HT. > > Thus the P4_NMI_IQ_CCCR0 of thread0 and thread1 go to the same register,i= .e, > overwritten. I wonder how NMI works on HT CPUs? I think it would make sen= se > to use two counters in HT mode, one for each CPU seen by the kernel. Yet > this may render certain user measurement impossible. > > > I am hoping this doesn't break your user space tools. As I don't > > really run oprofile, I don't know the right way to test this. Let me > > know if this is a better solution. > > I don't own OProfile tools. I think as a result of this change, user leve= l > code must take a look at /dev/oprofile to figure out what counters are ac= tually > available. They must be prepared to operate with fewer counters than expe= cted > for a given CPU. I don't know the internals of the OProfile tools, not su= re > they already have support for this. > Who owns the tool? I just figured this mailing list was the right place to post patches and ask questions about making internal changes? Perhaps I was wrong? Cheers, Don |