Messages in this thread | | | Date | Tue, 21 Jun 2011 20:06:54 +0200 | Subject | Re: [RFC -tip] perf, x86: Add PERF_COUNT_HW_NMI_WATCHDOG event v2 | From | Stephane Eranian <> |
| |
On Tue, Jun 21, 2011 at 7:54 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote: > On Tue, Jun 21, 2011 at 07:26:16PM +0200, Stephane Eranian wrote: > ... >> > >> > It doesn't change things much. Of course I can put some specifics into >> > .config but where is the guarantee some new generic event would not ever >> > intersect with it. I know (for example) we could reserve -1ULL for this >> > event but again where is the guarantee that it will never ever be used >> > system wide in future for some different event? >> > >> I am not talking about a new generic PMU event. I am talking about >> you hardcoding a raw event in the callback: type = PERF_TYPE_RAW, >> config=0x003c. >> > > watchdog.c is system-wide and even if it's not used by archs other > than x86 doesn't mean it'll not in future ;) So we could encode > this watchdog event as you mention (and I would check for this > values and map it internally to bits I need, this btw will require me > to check if this bits do not intersect with some already valid bits > combination but it's a different problem) but than we _must_ be sure it > never bring problems as new arch or consumer appear. So, no, I don't > like this approach, it's fragile. But gimme some time -- I'll re-check > all bits, probably there is some workaround. > I don't understand what possible conflict bits you're talking about
If in arch/x86/kernel/cpu/perf_event.c I add a callback which checks:
if (netburst_host) { attr.type = PERF_TYPE_RAW attr.config = 0x3c } else { attr.type = PERF_TYPE_HARDWARE attr.config = PERF_COUNT_HW__CPU_CYCLES }
I simply don't think PERF_COUNT_HW_NMI_WATCHDOG should ever be exposed to users.
> Cyrill > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |