lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ