History log of /freebsd-9.3-release/usr.sbin/pmccontrol/pmccontrol.c
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 267654 19-Jun-2014 gjb

Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 237969 02-Jul-2012 obrien

MFC: r227524: improve the grep-ability output strings.


# 229235 01-Jan-2012 dim

MFC r228671:

In usr.sbin/pmccontrol/pmccontrol.c, fix a few warnings about format
strings not being literals.


# 225736 22-Sep-2011 kensmith

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by: re (implicit)


# 224058 15-Jul-2011 attilio

Fix logical_cpus_mask retrieving by using, correctly, cpuset_t.
This fix also a bug where pmccontrol uses a 32 static type rather than
old cpumask_t.

Reported and reviewed by: avg


# 224057 15-Jul-2011 avg

pmcstat, pmccontrol: catch up with removal of machdep.hlt_cpus sysctl

Reported by: Pan Tsu <inyaoo@gmail.com>
Reviewed by: attilio
No objections: gnn


# 222813 07-Jun-2011 attilio

etire the cpumask_t type and replace it with cpuset_t usage.

This is intended to fix the bug where cpu mask objects are
capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever
value. Anyway, as long as several structures in the kernel are
statically allocated and sized as MAXCPU, it is suggested to keep it
as low as possible for the time being.

Technical notes on this commit itself:
- More functions to handle with cpuset_t objects are introduced.
The most notable are cpusetobj_ffs() (which calculates a ffs(3)
for a cpuset_t object), cpusetobj_strprint() (which prepares a string
representing a cpuset_t object) and cpusetobj_strscan() (which
creates a valid cpuset_t starting from a string representation).
- pc_cpumask and pc_other_cpus are target to be removed soon.
With the moving from cpumask_t to cpuset_t they are now inefficient
and not really useful. Anyway, for the time being, please note that
access to pcpu datas is protected by sched_pin() in order to avoid
migrating the CPU while reading more than one (possible) word
- Please note that size of cpuset_t objects may differ between kernel
and userland. While this is not directly related to the patch itself,
it is good to understand that concept and possibly use the patch
as a reference on how to deal with cpuset_t objects in userland, when
accessing kernland members.
- KTR_CPUMASK is changed and now is represented through a string, to be
set as the example reported in NOTES.

Please additively note that no MAXCPU is bumped in this patch, but
private testing has been done until to MAXCPU=128 on a real 8x8x2(htt)
machine (amd64).

Please note that the FreeBSD version is not yet bumped because of
the upcoming pcpu changes. However, note that this patch is not
targeted for MFC.

People to thank for the time spent on this patch:
- sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested
several revision of the patches and really helped in improving
stability of this work.
- marius fixed several bugs in the sparc64 implementation and reviewed
patches related to ktr.
- jeff and jhb discussed the basic approach followed.
- kib and marcel made targeted review on some specific part of the
patch.
- marius, art, nwhitehorn and andreast reviewed MD specific part of
the patch.
- marius, andreast, gonzo, nwhitehorn and jceel tested MD specific
implementations of the patch.
- Other people have made contributions on other patches that have been
already committed and have been listed separately.

Companies that should be mentioned for having participated at several
degrees:
- Yahoo! for having offered the machines used for testing on big
count of CPUs.
- The FreeBSD Foundation for having sponsored my devsummit attendance,
which has been instrumental.
- Sandvine for having offered offices and infrastructure during
development.

(I really hope I didn't forget anyone, if it happened I apologize in
advance).


# 213691 11-Oct-2010 gnn

Add code to print the number and type of the CPU that is present in
the system as well has how many PMCs there are per CPU. In this code
CPU and core are equivalent.

MFC after: 1 day


# 184998 16-Nov-2008 jkoshy

Ignore absent CPUs when listing the current state of PMC hardware.


# 184782 09-Nov-2008 jkoshy

Change the meaning of a "*" argument to option -c to mean 'all
unhalted CPUs', instead of 'all CPUs'. This change brings
pmccontrol(8) in line with pmcstat(8).


# 156065 27-Feb-2006 jkoshy

Fix pmccontrol(8) on Intel Xeon's running in 64 bit mode.

PR: kern/93773


# 150703 28-Sep-2005 jkoshy

The 'intr_bufferfull' driver statistic actually counts the number
of times sampling was stopped due to a space shortage; change its
description in the output of `pmcstat -s` to match reality.

MFC after: 3 days


# 147581 24-Jun-2005 jkoshy

Sync the usage message with the code.

Approved by: re (hwpmc blanket)
Pointed out by: ru


# 147191 09-Jun-2005 jkoshy

MFP4:

- Implement sampling modes and logging support in hwpmc(4).

- Separate MI and MD parts of hwpmc(4) and allow sharing of
PMC implementations across different architectures.
Add support for P4 (EMT64) style PMCs to the amd64 code.

- New pmcstat(8) options: -E (exit time counts) -W (counts
every context switch), -R (print log file).

- pmc(3) API changes, improve our ability to keep ABI compatibility
in the future. Add more 'alias' names for commonly used events.

- bug fixes & documentation.


# 145774 01-May-2005 jkoshy

Add convenience APIs pmc_width() and pmc_capabilities() to -lpmc.
Have pmcstat(8) and pmccontrol(8) use these APIs.

Return PMC class-related constants (PMC widths and capabilities)
with the OP GETCPUINFO call leaving OP PMCINFO to return only the
dynamic information associated with a PMC (i.e., whether enabled,
owner pid, reload count etc.).

Allow pmc_read() (i.e., OPS PMCRW) on active self-attached PMCs to
get upto-date values from hardware since we can guarantee that the
hardware is running the correct PMC at the time of the call.

Bug fixes:
- (x86 class processors) Fix a bug that prevented an RDPMC
instruction from being recognized as permitted till after the
attached process had context switched out and back in again after
a pmc_start() call.

Tighten the rules for using RDPMC class instructions: a GETMSR
OP is now allowed only after an OP ATTACH has been done by the
PMC's owner to itself. OP GETMSR is not allowed for PMCs that
track descendants, for PMCs attached to processes other than
their owner processes.

- (P4/HTT processors only) Fix a bug that caused the MI and MD
layers to get out of sync. Add a new MD operation 'get_config()'
as part of this fix.

- Allow multiple system-mode PMCs at the same row-index but on
different CPUs to be allocated.

- Reject allocation of an administratively disabled PMC.

Misc. code cleanups and refactoring. Improve a few comments.


# 145256 19-Apr-2005 jkoshy

Bring a working snapshot of hwpmc(4), its associated libraries, userland utilities
and documentation into -CURRENT.

Bump FreeBSD_version.

Reviewed by: alc, jhb (kernel changes)