[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18889.64659.917207.685779@cargo.ozlabs.ibm.com>
Date: Wed, 25 Mar 2009 20:42:43 +1100
From: Paul Mackerras <paulus@...ba.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf_counter: allow and require one-page mmap on
counting counters
Ingo Molnar writes:
> ah - ok. Morning confusion. (any email from me that comes at single
> digit hour local time should be considered fundamentally suspect ;-)
:)
> Wouldnt it still be better to keep the symmetry between counting and
> sampling counters? In theory we could transit between these stags
> and 'switch off' a sampling counter or 'switch on' a counting
> counter - via an ioctl or so. Shouldnt counting counters be sampling
> counters that were created while disabled temporarily?
Well, the buffer size can already be changed on the fly, by unmapping
the counter and remapping. So, shouldn't I be allowed to select a
zero-sized ring buffer at the times when I'm not sampling, i.e. when
it's a counting counter?
And here's something else that is semi-related: the PAPI guys want a
kind of counter that counts until it overflows, and then sends a
signal to the process and disables itself (and the whole group it's
in). The signal handler can then record whatever application-specific
information is interesting, re-enable the counter and return. It
seems to be a way to do profiling where what you're recording is
something specific to the program rather than generic things like the
instruction pointer.
So that could be a case where we want a sampling counter that doesn't
generate any event records in the kernel, and so a 0-sized ring buffer
could be appropriate.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists