From owner-freebsd-current@FreeBSD.ORG Sun May 25 07:11:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 321F13E7; Sun, 25 May 2014 07:11:25 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3AAD258E; Sun, 25 May 2014 07:11:24 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb1so6100654pad.9 for ; Sun, 25 May 2014 00:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7AQaHtohyq0rS/Lg4HWsoY/xs4eI1XUWX48NakLpUoc=; b=qJVzNjqVJouTADQkHXqeaPDJ9m0CSPmu7YElmQtMnt8vybUPjjUOggBwGqJirTrsD9 aqmkBLn6vKam1TMZSF04JNAdO1gCb9bbY+Zw6XVWi2BWokJa/neHd50Vva4Awep4E1sq R7hdmFD+YrOztqoRbZV6k8NB/JmrsnXaQ7VyWu2GzEgfokGujBLpshgSH6AneQ1toxYW tBsZIP93qcvepA30C2JuVUWh8tpPONXSrimMOFBu+hfIogzTQfgws4Js/ToB5UVfBxAi Vx5ndh9UNylnU8ywo4xHfHhI3JjcuJZUk7b+1GHZElpwZSCJLtm5GqP0pNswnDkdUlEX JigA== X-Received: by 10.68.129.132 with SMTP id nw4mr18961982pbb.46.1401001884547; Sun, 25 May 2014 00:11:24 -0700 (PDT) Received: from ?IPv6:2001:44b8:31ae:7b00:24bb:8736:cc4f:f940? (2001-44b8-31ae-7b00-24bb-8736-cc4f-f940.static.ipv6.internode.on.net. [2001:44b8:31ae:7b00:24bb:8736:cc4f:f940]) by mx.google.com with ESMTPSA id ox3sm12269816pbb.88.2014.05.25.00.11.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 May 2014 00:11:23 -0700 (PDT) Sender: Kubilay Kocak Message-ID: <53819789.8030304@FreeBSD.org> Date: Sun, 25 May 2014 17:11:05 +1000 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Allan Jude , freebsd-current@freebsd.org Subject: Re: Change top's notion of idle processes / threads References: <201405231605.26312.jhb@freebsd.org> <537FBC1F.6030408@freebsd.org> In-Reply-To: <537FBC1F.6030408@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 07:11:25 -0000 On 24/05/2014 7:22 AM, Allan Jude wrote: > On 2014-05-23 16:05, John Baldwin wrote: >> Right now, when top is set to not display idle processes or threads, it only >> displays processes or threads that are currently in a runnable state or have a >> non-zero %cpu. However, our %cpu is quite imprecise. I have patch to change >> top to instead compare the thread or processes runtime (ki_runtime in >> kinfo_proc) against the runtime of the thread or process the last time data >> was fetched. In essence, top will consider any thread that has run on a CPU >> since the last update as non-idle. The end result is that mostly-idle threads >> and processes will now be visible in top's idle display. Personally, I find >> this more useful (and find the current implementation completely useless). >> The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch >> >> Comments? >> > > I think this makes good sense. I would definitely prefer it. Would it > make sense to maybe preserve the old behaviour behind a command line flag? > And an update to top(8) reflecting the algo :) I know these little esoteric things could always do with more obvious breadcrumbs (like load average calcs, etc) for our future selves and others. +1 on the behavior change, not sure about retaining the old under a flag. Who might benefit from it? How do other OS top implementations calculate their idle? If there's other examples out there with the same (current) algo, then retaining compat might be worth it, such as for newly converted users -- Koobs