From owner-freebsd-stable@freebsd.org Fri Jun 22 15:38:03 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C3A8101EEC1 for ; Fri, 22 Jun 2018 15:38:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7FC7748D2 for ; Fri, 22 Jun 2018 15:38:02 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1fWO8F-000KRo-0U; Fri, 22 Jun 2018 18:37:51 +0300 Date: Fri, 22 Jun 2018 18:37:50 +0300 From: Slawa Olhovchenkov To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Warner Losh , FreeBSD-STABLE Mailing List Subject: Re: iostat busy value calculation Message-ID: <20180622153750.GA2488@zxy.spb.ru> References: <98c4156c-d2f0-f0c6-b859-9cea8ec29a42@quip.cz> <55731ed7-c9f5-1e39-9c09-b522e58b97a1@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55731ed7-c9f5-1e39-9c09-b522e58b97a1@quip.cz> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 15:38:03 -0000 On Wed, Jun 20, 2018 at 07:37:20PM +0200, Miroslav Lachman wrote: > > %busy comes from the devstat layer. It's defined as the percent of the > > time over the polling interval in which at least one transaction was > > awaiting completion by the lower layers. It's an imperfect measure of > > how busy the drives are (in ye-olden days, before tagged queuing and > > NCQ, it was OK because you had THE transaction pending and it was a good > > measure of how utilized things were. Now with concurrent I/O in flash > > devices, it's only an imperfect approximation). > > Yes, I am aware of this issue. This percentage is just "is it slightly > loaded or heavily loaded" indicator. for "heavily loaded" use average transaction time and average queue length