Date: Wed, 28 Nov 2007 00:42:08 -0500 From: Skip Ford <skip@menantico.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: hackers@FreeBSD.org Subject: Re: Updated procstat(1) Message-ID: <20071128054208.GA813@menantico.com> In-Reply-To: <20071127171228.N94692@fledge.watson.org> References: <20071127171228.N94692@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > I've updated the procstat(1) kernel patch and userland tool; the updated > version can be found at: > > http://www.watson.org/~robert/freebsd/20071127-procstat.tgz > > The new version includes a number of changes from the old version, > including: > > - "-a" now means "all processes", Thanks. :-) I'm a little surprised. You seemed pretty dedicated to a per-process tool. 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. > - Threads and processes are now sorted by pid and then tid. If processes > are specified manually by pid, they are not sorted, although their threads > will be. Nice. > - 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? > The last of these required new kernel changes, including an MD component. > I've tested the MD parts only on i386, although I have quick hacks at what > they should look like on amd64, arm, powerpc, sparc64, sun4v. I don't > promise these compile or work, but they might do. In sys/amd64/amd64/db_trace.c on line 537, change "SWWAPPED" to "SWAPPED". 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. Unfortunately, I can only test i386. -- Skip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071128054208.GA813>