FreeBSD Bugzilla – Attachment 184637 Details for
Bug 220947
sys/cam/cam_iosched.c: Fix a couple of typos in comments
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
Remember
[x]
|
Forgot Password
Login:
[x]
[patch]
sys/cam/cam_iosched.c: Fix a couple of typos in comments
sys-cam-cam_iosched.c-Fix-a-couple-of-typos.diff (text/plain), 5.66 KB, created by
Fabian Keil
on 2017-07-23 15:57:43 UTC
(
hide
)
Description:
sys/cam/cam_iosched.c: Fix a couple of typos in comments
Filename:
MIME Type:
Creator:
Fabian Keil
Created:
2017-07-23 15:57:43 UTC
Size:
5.66 KB
patch
obsolete
>From 2b6f5f64ba7b8b24e987e2005a749365c610a20d Mon Sep 17 00:00:00 2001 >From: Fabian Keil <fk@fabiankeil.de> >Date: Fri, 21 Jul 2017 11:57:10 +0200 >Subject: [PATCH] sys/cam/cam_iosched.c: Fix a couple of typos in comments > >The following unclear sentence from cam_iosched_get_write() >should probably be fixed as well but the intended meaning >wasn't obvious to me: >| Limiting the queue depth like this will also limit >| the write throughput and give and reads that want to compete to >| compete unfairly." > >In cam_iosched_next_bio() a comment still refers to >"the netflix scheduler" while it probably should refer >to "the dynamic I/O scheduler" to match the name change >done in r302163 and r302396. > >Obtained from: ElectroBSD >--- > sys/cam/cam_iosched.c | 26 +++++++++++++------------- > 1 file changed, 13 insertions(+), 13 deletions(-) > >diff --git a/sys/cam/cam_iosched.c b/sys/cam/cam_iosched.c >index b24f4ca6df48..76359e409534 100644 >--- a/sys/cam/cam_iosched.c >+++ b/sys/cam/cam_iosched.c >@@ -110,13 +110,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 >@@ -471,8 +471,8 @@ cam_iosched_bw_caniop(struct iop_stats *ios, struct bio *bp) > { > /* > * 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 >@@ -586,7 +586,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 >@@ -1147,7 +1147,7 @@ cam_iosched_put_back_trim(struct cam_iosched_softc *isc, struct bio *bp) > * 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 * >@@ -1168,9 +1168,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. > */ >@@ -1406,7 +1406,7 @@ cam_iosched_clr_work_flags(struct cam_iosched_softc *isc, uint32_t flags) > #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 >@@ -1415,7 +1415,7 @@ cam_iosched_clr_work_flags(struct cam_iosched_softc *isc, uint32_t flags) > * 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 >@@ -1459,7 +1459,7 @@ isqrt64(uint64_t val) > * (ah + al / R) * (bh + bl / R) > * ah * bh + (al * bh + ah * bl) / R + al * bl / R^2 > * >- * After multiplicaiton, we have to renormalize by multiply by >+ * After multiplication, we have to renormalize by multiply by > * R, so we wind up with > * ah * bh * R + al * bh + ah * bl + al * bl / R > * which turns out to be a very nice way to compute this value >@@ -1485,7 +1485,7 @@ cam_iosched_update(struct iop_stats *iop, sbintime_t sim_latency) > uint64_t var; > > /* >- * 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. > * >@@ -1520,7 +1520,7 @@ cam_iosched_update(struct iop_stats *iop, sbintime_t sim_latency) > * which is the formula used here to get a decent estimate of sd which > * we use to detect outliers. Note that when first starting up, it > * takes a while for emss sum of squares estimator to converge on a >- * good value. during this time, it can be less than ema^2. We >+ * good value. During this time, it can be less than ema^2. We > * compute a sd of 0 in that case, and ignore outliers. > */ > var = iop->emss - mul(iop->ema, iop->ema); >-- >2.13.2 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 220947
:
184637
|
185435