tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Another kvm user can go away?



On Fri, 30 Dec 2016, Christos Zoulas wrote:

In article <Pine.NEB.4.64.1612301632420.13360%speedy.whooppee.com@localhost>,
Paul Goyette  <paul%whooppee.com@localhost> wrote:
I have managed to provide access to all of the kernel history data via
sysctl, and I've come up with a modified version of vmstat(1) that can
read the data from sysctl rather than having to use kvm.

Diffs for sys/sys/kernhist.h and sys/kern/kern_history.c can be found at
www.netbsd.org/~pgoyette/my_vmstat/kernhist.diffs  In the same directory
you can find a source file my_vmstat.c (and its associated Makefile).

Please review and comment (preferably constructively), and let me know
what more needs to be done before it gets committed.

- You should use timespec instead of timeval

Hmmm, timeval is what exists within the internal kernhist records.  I
could change everything over to timespec, but that seems like it would
belong in a separate change.


- u_int32_t -> uint32_t

Yeah, I thought I got all of those.  There are a couple of pre-existing
uses of u_int32_t in the declaration and definition of funtion

	void kernhist_dumpmask(u_int32_t)

which should also be changed.

- count/xlate_t should be size_t/uint32_t not int

Done.

- size_t is printed with %zu not %zd

The printf()s are left-over debug code, will remove.

- I don't like all those linear searches/scans through things; there
 must be a more efficient way to do it.

I thought of inserting the table entries in sorted order, and doing
binary searches, but that seemed rather complicated.  There's a lot of
duplication in the text data, so the tables really don't get very
long.

- if find_string returns 0, you keep overwriting the 0'th entry?

No, the callers of find_string() simply use the result as the offset
to place in the export structure.  Each entry in the string data
(including the 0th entry) is only copied once, in its own loop at

        /* Now fill the text string area */
        for (i = 0; i < xlate_c; i++) {
		...

find_string() only returns 0 if a new string gets entered in the history
data while we're processing the history records, ie, a new history event
occurred, with unique function name or format string.  (It's also used
for history table entries that have never been used, and both the
in-kernel and userland printf() code skip printing of such records.)

We could try to add new strings, but that would require us some real
magic to recalculate the buffersize required and then reallocating the
buffer itself (why is there no kmem_realloc() function?).


+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+


Home | Main Index | Thread Index | Old Index