From owner-freebsd-questions@FreeBSD.ORG Sat Mar 7 07:33:28 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B78A106566C for ; Sat, 7 Mar 2009 07:33:28 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 787578FC08 for ; Sat, 7 Mar 2009 07:33:27 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 21DEAEB5466; Sat, 7 Mar 2009 09:10:10 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id D9C6A4509B; Sat, 7 Mar 2009 09:10:10 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXt4HwBJXJE4; Sat, 7 Mar 2009 09:10:10 +0200 (EET) Received: from kobe.laptop (adsl158-175.kln.forthnet.gr [62.1.61.175]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 77EF545088; Sat, 7 Mar 2009 09:10:10 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n277A9aV002714; Sat, 7 Mar 2009 09:10:09 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n277A8b6002713; Sat, 7 Mar 2009 09:10:08 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Polytropon References: <20090307074423.640ec208.freebsd@edvax.de> Date: Sat, 07 Mar 2009 09:10:08 +0200 In-Reply-To: <20090307074423.640ec208.freebsd@edvax.de> (Polytropon's message of "Sat, 7 Mar 2009 07:44:23 +0100") Message-ID: <87bpsdkdv3.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD Questions Subject: Re: Status field STATE in top(1) interactive mode X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 07:33:28 -0000 On Sat, 7 Mar 2009 07:44:23 +0100, Polytropon wrote: > Hi list, > > in order to find out why Opera often keeps hanging (doing nothing), > often for several minutes, I checked its top(1) output. > > Reading "man top", I found the following explaination: > > [...] STATE is the current state (one of "START", "RUN" > (shown as "CPUn" on SMP systems), "SLEEP", "STOP", "ZOMB", > "WAIT", "LOCK" or the event on which the process > waits) [...] > > When Opera just hangs(TM) :-), it is in one of the states "ucond" > or "umtxn" - and sucking up to 100% WCPU. > > Here is my question: Is there an explainative list that gives a > clue about what this state indicates? Where are these "event[s] > on which the process waits" documented? > > When I could guess, then I'd say that "ucond" means "unconditioned", > "in no condition" (which would be a very strage state - the absense of > any state), and "umtxn"... um... USB mass storage transmit number? No > idea. > > Other states that I see have a more descriptive name, such as "pause", > "select" or "getblk" and even "kqread". "umtx lock", "umtx", "umtxn", "umtxpi" and "umtxpp" are internal kernel strings that are used to identify particular locks and wait conditions where a process may block while running inside the kernel. A recent FreeBSD 8.0-CURRENT kernel shows: keramida@kobe:/usr/src/sys$ fgrep -r '"umtx' . ./kern/kern_umtx.c:static MALLOC_DEFINE(M_UMTX, "umtx", "UMTX queue memory"); ./kern/kern_umtx.c:SYSCTL_NODE(_debug, OID_AUTO, umtx, CTLFLAG_RW, 0, "umtx debug"); ./kern/kern_umtx.c: umtx_pi_zone = uma_zcreate("umtx pi", sizeof(struct umtx_pi), ./kern/kern_umtx.c: mtx_init(&umtxq_chains[i][j].uc_lock, "umtxql", NULL, ./kern/kern_umtx.c: mtx_init(&umtx_lock, "umtx lock", NULL, MTX_SPIN); ./kern/kern_umtx.c: msleep(uc, &uc->uc_lock, 0, "umtxqb", 0); ./kern/kern_umtx.c: error = umtxq_sleep(uq, "umtx", timo); ./kern/kern_umtx.c: error = umtxq_sleep(uq, "umtx", timo); ./kern/kern_umtx.c: error = umtxq_sleep(uq, "umtxn", timo); ./kern/kern_umtx.c: "umtxpi", timo); ./kern/kern_umtx.c: error = umtxq_sleep(uq, "umtxpp", timo); ./kern/kern_umtx.c: error = umtxq_sleep(uq, "umtxpp", 0); ./kern/subr_witness.c: { "umtx lock", &lock_class_mtx_spin }, keramida@kobe:/usr/src/sys$ AFAIK, there is no automated way of generating a list of kernel wait states for all possible locks and wait conditions in the kernel, and even if there was it would be a bit tricky to update the top(1) manpage to automagically include all of them. One of the reasons why this is a relatively Sisyphean effort is that you can run often run an old top(1) binary with both a matching kernel *and* a kernel that is a few snapshots newer. When this happens the new kernel may support wait states that are not included in the top(1) manpage at all.