Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1653025

Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter
Date 2017-05-30 11:30 +0200
Message-ID <tMLDs-5ux-37@gated-at.bofh.it> (permalink)
References (5 earlier) <tKbE5-7Qs-9@gated-at.bofh.it> <tKbNL-7U4-1@gated-at.bofh.it> <tKGHT-49Y-9@gated-at.bofh.it> <tKH1f-4vB-5@gated-at.bofh.it> <tMd8J-6Ob-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sun, May 28, 2017 at 01:31:09PM -0700, Stephane Eranian wrote:
> Ultimately, I would like to see the watchdog move out of the PMU. That
> is the only sensible solution.
> You just need a resource able to interrupt on NMI or you handle
> interrupt masking in software as has
> been proposed on LKML.

So even if we do the soft masking, we still need to deal with regions
where the interrupts are disabled. Once an interrupt hits the soft mask
we still hardware mask.

So to get full and reliable coverage we still need an NMI source.

I agree that it would be lovely to free up the one counter though.


One other approach is running the watchdog off of _any_ PMI, then all we
need to ensure is that PMIs happen semi regularly. There are two cases
where this becomes 'interesting':

 - we have only !sampling events; in this case we have PMIs but at the
   max period to properly account for counter overflow. This is too
   large a period. We'd have to muck with the max period of at least one
   counter.

 - we have _no_ events; in this case we need to somehow schedule an
   event anyway.

It might be possible to deal with both cases by fudging the state of one
of the fixed counters. Never clear the EN bit for that counter and
reduce the max period for that one counter.


I think a scheme like that was mentioned before, but I'm also afraid
that it'll turn into quite the mess if we try it. And by its very nature
it adds complexity and therefore risks reducing the reliability of the
thing :/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Stephane Eranian <eranian@google.com> - 2017-05-28 22:40 +0200
  Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Peter Zijlstra <peterz@infradead.org> - 2017-05-30 11:30 +0200
    Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Andi Kleen <ak@linux.intel.com> - 2017-05-30 16:00 +0200
      Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Peter Zijlstra <peterz@infradead.org> - 2017-05-30 18:30 +0200
        Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Stephane Eranian <eranian@google.com> - 2017-05-30 18:50 +0200
        Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Andi Kleen <ak@linux.intel.com> - 2017-05-30 19:30 +0200
          Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Peter Zijlstra <peterz@infradead.org> - 2017-05-30 19:50 +0200
            Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Andi Kleen <ak@linux.intel.com> - 2017-05-30 20:00 +0200
              Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Peter Zijlstra <peterz@infradead.org> - 2017-05-30 21:10 +0200
                Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Andi Kleen <ak@linux.intel.com> - 2017-05-30 21:50 +0200
    Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Stephane Eranian <eranian@google.com> - 2017-05-30 18:50 +0200
      Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP  counter Thomas Gleixner <tglx@linutronix.de> - 2017-05-30 19:00 +0200

csiph-web