Re: Updated procstat(1)


On Wed, 28 Nov 2007, Skip Ford wrote:

- "-a" now means "all processes",

Thanks. :-) I'm a little surprised. You seemed pretty dedicated to a per-process tool.

I was, but then I read your e-mail and became convinced that the first patch that would be submitted against procstat(1) would be a "-a" patch. :-)

I personally would change it to allow either the all flag or a list of pids, rather than "at least one of". For pathname, command-line, and credential information, the output will likely not change between showing the pid in the "all" output and the "list" output so you're just outputting it twice. If one really wants the same pid to be output multiple times for threads, kstack, or file descriptors, then I'd expect "procstat -k 0 0 0 0 0" to be more useful for that.

I would think a mistake in usage has been made if a list of pids is specified along with the "all" flag. But, no real harm is done by doing it the current way.

I think your argument is convincing, and have changed it so that only one of -a and a pidlist can be specified. I've also tightened down the syntax checking on flags a bit more.

- A new "-k" has been added, which prints the kernel thread stacks for threads
in a process (although not swapped out or actively running threads). This
is extremely useful for answering questions of the sort "But *why* is the
process blocked in UMA". It has both a simple mode (-k_, which lists just
kernel function names, and a slightly more detailed mode (-kk), which adds
the offset into the function.

This is excellent. Does this absolutely have to depend on DDB and KDB?

Currently, yes, as stack(9) is conditional on DDB, and the MD bits of stack(9) are defined in db_trace.c (and in some cases, depend on DDB definitions, such as DDB types, although I think not critically so). I've also been pondering breaking out stack(9) from DDB but haven't done that yet. Maybe that will be today's task, as I'd like -k to work without the kernel debugger, as it has use significantly beyond kernel debugging.

In sys/amd64/amd64/db_trace.c on line 537, change "SWWAPPED" to "SWAPPED".

Fixed, thanks.

The newly introducted function stack_save_td() doesn't panic in the MD powerpc code like it does for other arches. I have no idea if this is correct, it just doesn't match the others.

Indeed, and I've now fixed this, thanks!

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Extending the ddb command set
    ... commands to the set that is available in ddb. ... when invoking ddb, the command does not appear in the help list. ... linked lists now instead of arrays. ...
    (freebsd-hackers)
  • Re: Updated procstat(1)
    ... per-process tool. ... kernel function names, and a slightly more detailed mode, which ... Does this absolutely have to depend on DDB and KDB? ... kernel debugger, as it has use significantly beyond kernel debugging. ...
    (freebsd-hackers)
  • Re: Processes blocked on ufs or getblk
    ... When you reproduce it next time, do a "ps" in DDB to see what ... processes are stuck in UFS, and then do a "tr <pid>" on each one to ...
    (freebsd-current)