kstat.h revision b819cea2f73f98c5662230cc9affc8cc84f77fcf
/*
* CDDL HEADER START
*
* The contents of this file are subject to the terms of the
* Common Development and Distribution License (the "License").
* You may not use this file except in compliance with the License.
*
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
* See the License for the specific language governing permissions
* and limitations under the License.
*
* When distributing Covered Code, include this CDDL HEADER in each
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
* If applicable, add the following below this CDDL HEADER, with the
* fields enclosed by brackets "[]" replaced with your own identifying
* information: Portions Copyright [yyyy] [name of copyright owner]
*
* CDDL HEADER END
*/
/*
* Copyright 2006 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*
* Copyright 2013 Nexenta Systems, Inc. All rights reserved.
*/
#ifndef _SYS_KSTAT_H
#define _SYS_KSTAT_H
/*
*/
#ifdef __cplusplus
extern "C" {
#endif
typedef int kid_t; /* unique kstat id */
/*
*/
/*
*
* kcid = ioctl(kd, KSTAT_IOC_CHAIN_ID, NULL);
* kcid = ioctl(kd, KSTAT_IOC_READ, kstat_t *);
* kcid = ioctl(kd, KSTAT_IOC_WRITE, kstat_t *);
*/
/*
* The generic kstat header
*/
typedef struct kstat {
/*
* Fields relevant to both kernel and user
*/
int ks_instance; /* provider module's instance */
void *ks_data; /* kstat type-specific data */
/*
* Fields relevant to kernel only
*/
void *ks_private; /* arbitrary provider-private data */
int (*ks_snapshot)(struct kstat *, void *, int);
void *ks_lock; /* protects this kstat's data */
} kstat_t;
#ifdef _SYSCALL32
typedef struct kstat32 {
/*
* Fields relevant to both kernel and user
*/
char ks_module[KSTAT_STRLEN];
char ks_name[KSTAT_STRLEN];
char ks_class[KSTAT_STRLEN];
/*
* Fields relevant to kernel only (only needed here for padding)
*/
} kstat32_t;
#endif /* _SYSCALL32 */
/*
* kstat structure and locking strategy
*
* Each kstat consists of a header section (a kstat_t) and a data section.
* The system maintains a set of kstats, protected by kstat_chain_lock.
* as well as all changes to kstat headers. kstat data sections are
* *optionally* protected by the per-kstat ks_lock. If ks_lock is non-NULL,
* operations on that kstat. It is up to the kstat provider to decide whether
* guaranteeing consistent data to kstat clients is sufficiently important
* to justify the locking cost. Note, however, that most statistic updates
* already occur under one of the provider's mutexes, so if the provider sets
* ks_lock to point to that mutex, then kstat data locking is free.
*
* NOTE: variable-size kstats MUST employ kstat data locking, to prevent
* data-size races with kstat clients.
*
* NOTE: ks_lock is really of type (kmutex_t *); it is declared as (void *)
* in the kstat header so that users don't have to be exposed to all of the
* kernel's lock-related data structures.
*/
#if defined(_KERNEL)
#define KSTAT_ENTER(k) \
#define KSTAT_EXIT(k) \
#endif /* defined(_KERNEL) */
/*
* kstat time
*
* All times associated with kstats (e.g. creation time, snapshot time,
* kstat_timer_t and kstat_io_t timestamps, etc.) are 64-bit nanosecond values,
* as returned by gethrtime(). The accuracy of these timestamps is machine
* dependent, but the precision (units) is the same across all platforms.
*/
/*
* kstat identity (KID)
*
* Each kstat is assigned a unique KID (kstat ID) when it is added to the
* request information about the corresponding kstat. There is also
* an identity associated with the entire kstat chain, kstat_chain_id,
* the chain ID to detect changes in the kstat chain (e.g., a new disk
* coming online) between ioctl()s.
*/
/*
* kstat module, kstat instance
*
* ks_module and ks_instance contain the name and instance of the module
* that created the kstat. In cases where there can only be one instance,
* module name.
*/
/*
* kstat name
*
* ks_name gives a meaningful name to a kstat. The full kstat namespace
* is module.instance.name, so the name only need be unique within a
* module. kstat_create() will fail if you try to create a kstat with
* an already-used (ks_module, ks_instance, ks_name) triplet. Spaces are
* allowed in kstat names, but strongly discouraged, since they hinder
* awk-style processing at user level.
*/
/*
* kstat type
*
* The kstat mechanism provides several flavors of kstat data, defined
* below. The "raw" kstat type is just treated as an array of bytes; you
* can use this to export any kind of data you want.
*
* Some kstat types allow multiple data structures per kstat, e.g.
* KSTAT_TYPE_NAMED; others do not. This is part of the spec for each
* kstat data type.
*
* User-level tools should *not* rely on the #define KSTAT_NUM_TYPES. To
* get this information, read out the standard system kstat "kstat_types".
*/
#define KSTAT_TYPE_RAW 0 /* can be anything */
/* ks_ndata >= 1 */
/* ks_ndata >= 1 */
/* ks_ndata == 1 */
/* ks_ndata == 1 */
/* ks_ndata >= 1 */
#define KSTAT_NUM_TYPES 5
/*
* kstat class
*
* Each kstat can be characterized as belonging to some broad class
* of statistics, e.g. disk, tape, net, vm, streams, etc. This field
* can be used as a filter to extract related kstats. The following
* values are currently in use: disk, tape, net, controller, vm, kvm,
* hat, streams, kstat, and misc. (The kstat class encompasses things
* like kstat_types.)
*/
/*
* kstat flags
*
* Any of the following flags may be passed to kstat_create(). They are
* all zero by default.
*
* KSTAT_FLAG_VIRTUAL:
*
* Tells kstat_create() not to allocate memory for the
* kstat data section; instead, you will set the ks_data
* field to point to the data you wish to export. This
* provides a convenient way to export existing data
* structures.
*
* KSTAT_FLAG_VAR_SIZE:
*
* The size of the kstat you are creating will vary over time.
* For example, you may want to use the kstat mechanism to
* export a linked list. NOTE: The kstat framework does not
* manage the data section, so all variable-size kstats must be
* virtual kstats. Moreover, variable-size kstats MUST employ
* kstat data locking to prevent data-size races with kstat
* clients. See the section on "kstat snapshot" for details.
*
* KSTAT_FLAG_WRITABLE:
*
* Makes the kstat's data section writable by root.
* The ks_snapshot routine (see below) does not need to check for
* this; permission checking is handled in the kstat driver.
*
* KSTAT_FLAG_PERSISTENT:
*
* Indicates that this kstat is to be persistent over time.
* For persistent kstats, kstat_delete() simply marks the
* kstat as dormant; a subsequent kstat_create() reactivates
* the kstat. This feature is provided so that statistics
* on a disk with no mounted partitions.)
* NOTE: Persistent kstats cannot be virtual, since ks_data
* points to garbage as soon as the driver goes away.
*
* The following flags are maintained by the kstat framework:
*
* KSTAT_FLAG_DORMANT:
*
* For persistent kstats, indicates that the kstat is in the
* dormant state (e.g., the corresponding device is closed).
*
* KSTAT_FLAG_INVALID:
*
* This flag is set when a kstat is in a transitional state,
* e.g. between kstat_create() and kstat_install().
* kstat clients must not attempt to access the kstat's data
* if this flag is set.
*/
#define KSTAT_FLAG_VIRTUAL 0x01
#define KSTAT_FLAG_VAR_SIZE 0x02
#define KSTAT_FLAG_WRITABLE 0x04
#define KSTAT_FLAG_PERSISTENT 0x08
#define KSTAT_FLAG_DORMANT 0x10
#define KSTAT_FLAG_INVALID 0x20
/*
* Dynamic update support
*
* The kstat mechanism allows for an optional ks_update function to update
* kstat data. This is useful for drivers where the underlying device
* keeps cheap hardware stats, but extraction is expensive. Instead of
* constantly keeping the kstat data section up to date, you can supply a
* ks_update function which updates the kstat's data section on demand.
* To take advantage of this feature, simply set the ks_update field before
* calling kstat_install().
*
* The ks_update function, if supplied, must have the following structure:
*
* int
* foo_kstat_update(kstat_t *ksp, int rw)
* {
* if (rw == KSTAT_WRITE) {
* ... update the native stats from ksp->ks_data;
* return EACCES if you don't support this
* } else {
* ... update ksp->ks_data from the native stats
* }
* }
*
* The ks_update return codes are: 0 for success, EACCES if you don't allow
* KSTAT_WRITE, and EIO for any other type of error.
*
* In general, the ks_update function may need to refer to provider-private
* data; for example, it may need a pointer to the provider's raw statistics.
* The ks_private field is available for this purpose. Its use is entirely
* at the provider's discretion.
*
* All variable-size kstats MUST supply a ks_update routine, which computes
* and sets ks_data_size (and ks_ndata if that is meaningful), since these
* are needed to perform kstat snapshots (see below).
*
* No kstat locking should be done inside the ks_update routine. The caller
* will already be holding the kstat's ks_lock (to ensure consistent data).
*/
#define KSTAT_READ 0
#define KSTAT_WRITE 1
/*
* Kstat snapshot
*
* In order to get a consistent view of a kstat's data, clients must obey
* the kstat's locking strategy. However, these clients may need to perform
* operations on the data which could cause a fault (e.g. copyout()), or
* operations which are simply expensive. Doing so could cause deadlock
* (e.g. if you're holding a disk's kstat lock which is ultimately required
* to resolve a copyout() fault), performance degradation (since the providers'
* activity is serialized at the kstat lock), device timing problems, etc.
*
* To avoid these problems, kstat data is provided via snapshots. Taking
* a snapshot is a simple process: allocate a wired-down kernel buffer,
* acquire the kstat's data lock, copy the data into the buffer ("take the
* snapshot"), and release the lock. This ensures that the kstat's data lock
* will be held as briefly as possible, and that no faults will occur while
* the lock is held.
*
* Normally, the snapshot is taken by default_kstat_snapshot(), which
* timestamps the data (sets ks_snaptime), copies it, and does a little
* massaging to deal with incomplete transactions on i/o kstats. However,
* this routine only works for kstats with contiguous data (the typical case).
* If you create a kstat whose data is, say, a linked list, you must provide
* your own ks_snapshot routine. The routine you supply must have the
* following prototype (replace "foo" with something appropriate):
*
* int foo_kstat_snapshot(kstat_t *ksp, void *buf, int rw);
*
* The minimal snapshot routine -- one which copies contiguous data that
* doesn't need any massaging -- would be this:
*
* ksp->ks_snaptime = gethrtime();
* if (rw == KSTAT_WRITE)
* bcopy(buf, ksp->ks_data, ksp->ks_data_size);
* else
* bcopy(ksp->ks_data, buf, ksp->ks_data_size);
* return (0);
*
* A more illuminating example is taking a snapshot of a linked list:
*
* ksp->ks_snaptime = gethrtime();
* if (rw == KSTAT_WRITE)
* return (EACCES); ... See below ...
* for (foo = first_foo; foo; foo = foo->next) {
* bcopy((char *) foo, (char *) buf, sizeof (struct foo));
* buf = ((struct foo *) buf) + 1;
* }
* return (0);
*
* In the example above, we have decided that we don't want to allow
* KSTAT_WRITE access, so we return EACCES if this is attempted.
*
* The key points are:
*
* (1) ks_snaptime must be set (via gethrtime()) to timestamp the data.
* (2) Data gets copied from the kstat to the buffer on KSTAT_READ,
* and from the buffer to the kstat on KSTAT_WRITE.
* (3) ks_snapshot return values are: 0 for success, EACCES if you
* don't allow KSTAT_WRITE, and EIO for any other type of error.
*
* Named kstats (see section on "Named statistics" below) containing long
* strings (KSTAT_DATA_STRING) need special handling. The kstat driver
* assumes that all strings are copied into the buffer after the array of
* named kstats, and the pointers (KSTAT_NAMED_STR_PTR()) are updated to point
* into the copy within the buffer. The default snapshot routine does this,
* but overriding routines should contain at least the following:
*
* if (rw == KSTAT_READ) {
* kstat_named_t *knp = buf;
* char *end = knp + ksp->ks_ndata;
* uint_t i;
*
* ... Do the regular copy ...
* bcopy(ksp->ks_data, buf, sizeof (kstat_named_t) * ksp->ks_ndata);
*
* for (i = 0; i < ksp->ks_ndata; i++, knp++) {
* if (knp[i].data_type == KSTAT_DATA_STRING &&
* KSTAT_NAMED_STR_PTR(knp) != NULL) {
* bcopy(KSTAT_NAMED_STR_PTR(knp), end,
* KSTAT_NAMED_STR_BUFLEN(knp));
* KSTAT_NAMED_STR_PTR(knp) = end;
* end += KSTAT_NAMED_STR_BUFLEN(knp);
* }
* }
*/
/*
* Named statistics.
*
* List of arbitrary name=value statistics.
*/
typedef struct kstat_named {
union {
char c[16]; /* enough for 128-bit ints */
struct {
union {
char *ptr; /* NULL-term string */
#if defined(_KERNEL) && defined(_MULTI_DATAMODEL)
#endif
} addr;
} str;
/*
* The int64_t and uint64_t types are not valid for a maximally conformant
* 32-bit compilation environment (cc -Xc) using compilers prior to the
* In these cases, the visibility of i64 and ui64 is only permitted for
* 64-bit compilation environments or 32-bit non-maximally conformant
* C89 or C90 ANSI C compilation environments (cc -Xt and cc -Xa). In the
* C99 ANSI C compilation environment, the long long type is supported.
* The _INT64_TYPE is defined by the implementation (see sys/int_types.h).
*/
#if defined(_INT64_TYPE)
#endif
long l;
/* These structure members are obsolete */
float f;
double d;
} value; /* value of counter */
#define KSTAT_DATA_CHAR 0
#define KSTAT_DATA_INT32 1
#define KSTAT_DATA_UINT32 2
#define KSTAT_DATA_INT64 3
#define KSTAT_DATA_UINT64 4
#if !defined(_LP64)
#define KSTAT_DATA_LONG KSTAT_DATA_INT32
#define KSTAT_DATA_ULONG KSTAT_DATA_UINT32
#else
#if !defined(_KERNEL)
#define KSTAT_DATA_LONG KSTAT_DATA_INT64
#define KSTAT_DATA_ULONG KSTAT_DATA_UINT64
#else
#endif /* !_KERNEL */
#endif /* !_LP64 */
/*
* Statistics exporting named kstats with long strings (KSTAT_DATA_STRING)
* may not make the assumption that ks_data_size is equal to (ks_ndata * sizeof
* (kstat_named_t)). ks_data_size in these cases is equal to the sum of the
* amount of space required to store the strings (ie, the sum of
* KSTAT_NAMED_STR_BUFLEN() for all KSTAT_DATA_STRING statistics) plus the
* space required to store the kstat_named_t's.
*
* The default update routine will update ks_data_size automatically for
* variable-length kstats containing long strings (using the default update
* routine only makes sense if the string is the only thing that is changing
* in size, and ks_ndata is constant). Fixed-length kstats containing long
* strings must explicitly change ks_data_size (after creation but before
* initialization) to reflect the correct amount of space required for the
* long strings and the kstat_named_t's.
*/
#define KSTAT_DATA_STRING 9
/* These types are obsolete */
#define KSTAT_DATA_LONGLONG KSTAT_DATA_INT64
#define KSTAT_DATA_FLOAT 5
#define KSTAT_DATA_DOUBLE 6
/*
* Retrieve the pointer of the string contained in the given named kstat.
*/
/*
* Retrieve the length of the buffer required to store the string in the given
* named kstat.
*/
/*
* Interrupt statistics.
*
* An interrupt is a hard interrupt (sourced from the hardware device
* itself), a soft interrupt (induced by the system via the use of
* some system interrupt source), a watchdog interrupt (induced by
* a periodic timer call), spurious (an interrupt entry point was
* entered but there was no interrupt condition to service),
* or multiple service (an interrupt condition was detected and
* serviced just prior to returning from any of the other types).
*
* Measurement of the spurious class of interrupts is useful for
* autovectored devices in order to pinpoint any interrupt latency
* problems in a particular system configuration.
*
* Devices that have more than one interrupt of the same
* type should use multiple structures.
*/
#define KSTAT_INTR_HARD 0
#define KSTAT_INTR_SOFT 1
#define KSTAT_INTR_WATCHDOG 2
#define KSTAT_INTR_SPURIOUS 3
#define KSTAT_INTR_MULTSVC 4
#define KSTAT_NUM_INTRS 5
typedef struct kstat_intr {
} kstat_intr_t;
/*
* I/O statistics.
*/
typedef struct kstat_io {
/*
* Basic counters.
*
* The counters should be updated at the end of service
* (e.g., just prior to calling biodone()).
*/
/*
* Accumulated time and queue length statistics.
*
* Accumulated time statistics are kept as a running sum
* of "active" time. Queue length statistics are kept as a
* running sum of the product of queue length and elapsed time
* at that length -- i.e., a Riemann sum for queue length
* integrated against time. (You can also think of the active time
* as a Riemann sum, for the boolean function (queue_length > 0)
* integrated against time, or you can think of it as the
* Lebesgue measure of the set on which queue_length > 0.)
*
* ^
* | _________
* 8 | i4 |
* | | |
* Queue 6 | |
* Length | _________ | |
* 4 | i2 |_______| |
* | | i3 |
* 2_______| |
* | i1 |
* |_______________________________|
* Time-> t1 t2 t3 t4
*
* At each change of state (entry or exit from the queue),
* we add the elapsed time (since the previous state change)
* to the active time if the queue length was non-zero during
* that interval; and we add the product of the elapsed time
* times the queue length to the running length*time sum.
*
* This method is generalizable to measuring residency
* in any defined system: instead of queue lengths, think
* of "outstanding RPC calls to server X".
*
* A large number of I/O subsystems have at least two basic
* "lists" of transactions they manage: one for transactions
* that have been accepted for processing but for which processing
* has yet to begin, and one for transactions which are actively
* being processed (but not done). For this reason, two cumulative
* time statistics are defined here: wait (pre-service) time,
* and run (service) time.
*
* All times are 64-bit nanoseconds (hrtime_t), as returned by
* gethrtime().
*
* The units of cumulative busy time are accumulated nanoseconds.
* The units of cumulative length*time products are elapsed time
* times queue length.
*
* Updates to the fields below are performed implicitly by calls to
* these five functions:
*
* kstat_waitq_enter()
* kstat_waitq_exit()
* kstat_runq_enter()
* kstat_runq_exit()
*
* kstat_waitq_to_runq() (see below)
* kstat_runq_back_to_waitq() (see below)
*
* Since kstat_waitq_exit() is typically followed immediately
* by kstat_runq_enter(), there is a single kstat_waitq_to_runq()
* function which performs both operations. This is a performance
* win since only one timestamp is required.
*
* In some instances, it may be necessary to move a request from
* the run queue back to the wait queue, e.g. for write throttling.
* For these situations, call kstat_runq_back_to_waitq().
*
* These fields should never be updated by any other means.
*/
} kstat_io_t;
/*
* Event timer statistics - cumulative elapsed time and number of events.
*
* Updates to these fields are performed implicitly by calls to
* kstat_timer_start() and kstat_timer_stop().
*/
typedef struct kstat_timer {
#if defined(_KERNEL) || defined(_FAKE_KERNEL)
extern void kstat_init(void); /* initialize kstat framework */
/*
* Adding and deleting kstats.
*
* The typical sequence to add a kstat is:
*
* ksp = kstat_create(module, instance, name, class, type, ndata, flags);
* if (ksp) {
* ... provider initialization, if necessary
* kstat_install(ksp);
* }
*
* There are three logically distinct steps here:
*
* Step 1: System Initialization (kstat_create)
*
* kstat_create() performs system initialization. kstat_create()
* allocates memory for the entire kstat (header plus data), initializes
* all header fields, initializes the data section to all zeroes, assigns
* a unique KID, and puts the kstat onto the system's kstat chain.
* The returned kstat is marked invalid (KSTAT_FLAG_INVALID is set),
* because the provider (caller) has not yet had a chance to initialize
* the data section.
*
* By default, kstats are exported to all zones on the system. A kstat may be
* created via kstat_create_zone() to specify a zone to which the statistics
* should be exported. kstat_zone_add() may be used to specify additional
* zones to which the statistics are to be exported.
*
* Step 2: Provider Initialization
*
* The provider performs any necessary initialization of the data section,
* e.g. setting the name fields in a KSTAT_TYPE_NAMED. Virtual kstats set
* the ks_data field at this time. The provider may also set the ks_update,
* ks_snapshot, ks_private, and ks_lock fields if necessary.
*
* Step 3: Installation (kstat_install)
*
* Once the kstat is completely initialized, kstat_install() clears the
* INVALID flag, thus making the kstat accessible to the outside world.
* kstat_install() also clears the DORMANT flag for persistent kstats.
*
* Removing a kstat from the system
*
* kstat_delete(ksp) removes ksp from the kstat chain and frees all
* associated system resources. NOTE: When you call kstat_delete(),
* you must NOT be holding that kstat's ks_lock. Otherwise, you may
* deadlock with a kstat reader.
*
* Persistent kstats
*
* From the provider's point of view, persistence is transparent. The only
* difference between ephemeral (normal) kstats and persistent kstats
* is that you pass KSTAT_FLAG_PERSISTENT to kstat_create(). Magically,
* this has the effect of making your data visible even when you're
* not home. Persistence is important to tools like iostat, which want
* to get a meaningful picture of disk activity. Without persistence,
* raw disk i/o statistics could never accumulate: they would come and
*
* The magic of persistence works by slightly altering the behavior of
* kstat_create() and kstat_delete(). The first call to kstat_create()
* creates a new kstat, as usual. However, kstat_delete() does not
* actually delete the kstat: it performs one final update of the data
* (i.e., calls the ks_update routine), marks the kstat as dormant, and
* sets the ks_lock, ks_update, ks_private, and ks_snapshot fields back
* to their default values (since they might otherwise point to garbage,
* e.g. if the provider is going away). kstat clients can still access
* the dormant kstat just like a live kstat; they just continue to see
* the final data values as long as the kstat remains dormant.
* All subsequent kstat_create() calls simply find the already-existing,
* dormant kstat and return a pointer to it, without altering any fields.
* The provider then performs its usual initialization sequence, and
* calls kstat_install(). kstat_install() uses the old data values to
* initialize the native data (i.e., ks_update is called with KSTAT_WRITE),
* thus making it seem like you were never gone.
*/
extern kstat_t *kstat_create(const char *, int, const char *, const char *,
extern kstat_t *kstat_create_zone(const char *, int, const char *,
extern void kstat_install(kstat_t *);
extern void kstat_delete(kstat_t *);
extern void kstat_set_string(char *, const char *);
extern void kstat_delete_byname(const char *, int, const char *);
extern void kstat_delete_byname_zone(const char *, int, const char *, zoneid_t);
extern void kstat_timer_init(kstat_timer_t *, const char *);
extern void kstat_waitq_enter(kstat_io_t *);
extern void kstat_waitq_exit(kstat_io_t *);
extern void kstat_runq_enter(kstat_io_t *);
extern void kstat_runq_exit(kstat_io_t *);
extern void kstat_waitq_to_runq(kstat_io_t *);
extern void kstat_runq_back_to_waitq(kstat_io_t *);
extern void kstat_timer_start(kstat_timer_t *);
extern void kstat_timer_stop(kstat_timer_t *);
extern void kstat_rele(kstat_t *);
#endif /* defined(_KERNEL) */
#ifdef __cplusplus
}
#endif
#endif /* _SYS_KSTAT_H */