Date: Wed, 28 Nov 2007 09:33:38 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Skip Ford <skip@menantico.com> Cc: hackers@FreeBSD.org Subject: Re: Updated procstat(1) Message-ID: <20071128092434.J94692@fledge.watson.org> In-Reply-To: <20071128054208.GA813@menantico.com> References: <20071127171228.N94692@fledge.watson.org> <20071128054208.GA813@menantico.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071128092434.J94692>