From owner-svn-src-all@freebsd.org Fri Aug 18 16:38:34 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3716DC6129; Fri, 18 Aug 2017 16:38:34 +0000 (UTC) (envelope-from emaste@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (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 B9CCD6BDC4; Fri, 18 Aug 2017 16:38:34 +0000 (UTC) (envelope-from emaste@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v7IGcXYD019835; Fri, 18 Aug 2017 16:38:33 GMT (envelope-from emaste@FreeBSD.org) Received: (from emaste@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v7IGcXvn019834; Fri, 18 Aug 2017 16:38:33 GMT (envelope-from emaste@FreeBSD.org) Message-Id: <201708181638.v7IGcXvn019834@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: emaste set sender to emaste@FreeBSD.org using -f From: Ed Maste Date: Fri, 18 Aug 2017 16:38:33 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r322664 - head/sys/cam X-SVN-Group: head X-SVN-Commit-Author: emaste X-SVN-Commit-Paths: head/sys/cam X-SVN-Commit-Revision: 322664 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 16:38:35 -0000 Author: emaste Date: Fri Aug 18 16:38:33 2017 New Revision: 322664 URL: https://svnweb.freebsd.org/changeset/base/322664 Log: cam iosched: fix typos in comments PR: 220947 Submitted by: Fabian Keil Obtained from: ElectroBSD Modified: head/sys/cam/cam_iosched.c Modified: head/sys/cam/cam_iosched.c ============================================================================== --- head/sys/cam/cam_iosched.c Fri Aug 18 16:14:41 2017 (r322663) +++ head/sys/cam/cam_iosched.c Fri Aug 18 16:38:33 2017 (r322664) @@ -130,13 +130,13 @@ typedef int l_tick_t(struct iop_stats *); /* * Called to see if the limiter thinks this IOP can be allowed to - * proceed. If so, the limiter assumes that the while IOP proceeded + * proceed. If so, the limiter assumes that the IOP proceeded * and makes any accounting of it that's needed. */ typedef int l_iop_t(struct iop_stats *, struct bio *); /* - * Called when an I/O completes so the limiter can updates its + * Called when an I/O completes so the limiter can update its * accounting. Pending I/Os may complete in any order (even when * sent to the hardware at the same time), so the limiter may not * make any assumptions other than this I/O has completed. If it @@ -493,8 +493,8 @@ cam_iosched_bw_caniop(struct iop_stats *ios, struct bi { /* * So if we have any more bw quota left, allow it, - * otherwise wait. Not, we'll go negative and that's - * OK. We'll just get a lettle less next quota. + * otherwise wait. Note, we'll go negative and that's + * OK. We'll just get a little less next quota. * * Note on going negative: that allows us to process * requests in order better, since we won't allow @@ -639,7 +639,7 @@ cam_iosched_cl_maybe_steer(struct control_loop *clp) * ~10. At .25 it only takes ~8. However some preliminary data * from the SSD drives suggests a reasponse time in 10's of * seconds before latency drops regardless of the new write - * rate. Careful observation will be reqiured to tune this + * rate. Careful observation will be required to tune this * effectively. * * Also, when there's no read traffic, we jack up the write @@ -1214,7 +1214,7 @@ cam_iosched_put_back_trim(struct cam_iosched_softc *is * gets the next trim from the trim queue. * * Assumes we're called with the periph lock held. It removes this - * trim from the queue and the device must explicitly reinstert it + * trim from the queue and the device must explicitly reinsert it * should the need arise. */ struct bio * @@ -1235,9 +1235,9 @@ cam_iosched_next_trim(struct cam_iosched_softc *isc) } /* - * gets the an available trim from the trim queue, if there's no trim + * gets an available trim from the trim queue, if there's no trim * already pending. It removes this trim from the queue and the device - * must explicitly reinstert it should the need arise. + * must explicitly reinsert it should the need arise. * * Assumes we're called with the periph lock held. */ @@ -1476,7 +1476,7 @@ cam_iosched_clr_work_flags(struct cam_iosched_softc *i #ifdef CAM_IOSCHED_DYNAMIC /* * After the method presented in Jack Crenshaw's 1998 article "Integer - * Suqare Roots," reprinted at + * Square Roots," reprinted at * http://www.embedded.com/electronics-blogs/programmer-s-toolbox/4219659/Integer-Square-Roots * and well worth the read. Briefly, we find the power of 4 that's the * largest smaller than val. We then check each smaller power of 4 to @@ -1485,7 +1485,7 @@ cam_iosched_clr_work_flags(struct cam_iosched_softc *i * accumulating the right answer. It could also have been accumulated * using a separate root counter, but this code is smaller and faster * than that method. This method is also integer size invariant. - * It returns floor(sqrt((float)val)), or the larget integer less than + * It returns floor(sqrt((float)val)), or the largest integer less than * or equal to the square root. */ static uint64_t @@ -1553,7 +1553,7 @@ cam_iosched_update(struct iop_stats *iop, sbintime_t s iop->latencies[i]++; /* Put all > 1024ms values into the last bucket. */ /* - * Classic expoentially decaying average with a tiny alpha + * Classic exponentially decaying average with a tiny alpha * (2 ^ -alpha_bits). For more info see the NIST statistical * handbook. *