From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "tj@kernel.org" <tj@kernel.org>,
"paolo.valente@linaro.org" <paolo.valente@linaro.org>,
"axboe@kernel.dk" <axboe@kernel.dk>
Cc: "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"fchecconi@gmail.com" <fchecconi@gmail.com>,
"avanzini.arianna@gmail.com" <avanzini.arianna@gmail.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: [PATCH V2 04/16] block, bfq: modify the peak-rate estimator
Date: Fri, 31 Mar 2017 15:31:44 +0000 [thread overview]
Message-ID: <1490974279.2587.5.camel@sandisk.com> (raw)
In-Reply-To: <20170331124743.3530-5-paolo.valente@linaro.org>
On Fri, 2017-03-31 at 14:47 +0200, Paolo Valente wrote:
> -static bool bfq_update_peak_rate(struct bfq_data *bfqd, struct bfq_queue=
*bfqq,
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 bool compensate)
> +static bool bfq_bfqq_is_slow(struct bfq_data *bfqd, struct bfq_queue *bf=
qq,
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 bool compensate, enum bfqq_expiration reason,
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 unsigned long *delta_ms)
> =A0{
> -=A0=A0=A0=A0=A0=A0=A0u64 bw, usecs, expected, timeout;
> -=A0=A0=A0=A0=A0=A0=A0ktime_t delta;
> -=A0=A0=A0=A0=A0=A0=A0int update =3D 0;
> +=A0=A0=A0=A0=A0=A0=A0ktime_t delta_ktime;
> +=A0=A0=A0=A0=A0=A0=A0u32 delta_usecs;
> +=A0=A0=A0=A0=A0=A0=A0bool slow =3D BFQQ_SEEKY(bfqq); /* if delta too sho=
rt, use seekyness */
> =A0
> -=A0=A0=A0=A0=A0=A0=A0if (!bfq_bfqq_sync(bfqq) || bfq_bfqq_budget_new(bfq=
q))
> +=A0=A0=A0=A0=A0=A0=A0if (!bfq_bfqq_sync(bfqq))
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return false;
> =A0
> =A0=A0=A0=A0=A0=A0=A0=A0if (compensate)
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0delta =3D bfqd->last_idling=
_start;
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0delta_ktime =3D bfqd->last_=
idling_start;
> =A0=A0=A0=A0=A0=A0=A0=A0else
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0delta =3D ktime_get();
> -=A0=A0=A0=A0=A0=A0=A0delta =3D ktime_sub(delta, bfqd->last_budget_start)=
;
> -=A0=A0=A0=A0=A0=A0=A0usecs =3D ktime_to_us(delta);
> -
> -=A0=A0=A0=A0=A0=A0=A0/* Don't trust short/unrealistic values. */
> -=A0=A0=A0=A0=A0=A0=A0if (usecs < 100 || usecs >=3D LONG_MAX)
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return false;
> -
> -=A0=A0=A0=A0=A0=A0=A0/*
> -=A0=A0=A0=A0=A0=A0=A0 * Calculate the bandwidth for the last slice.=A0 W=
e use a 64 bit
> -=A0=A0=A0=A0=A0=A0=A0 * value to store the peak rate, in sectors per use=
c in fixed
> -=A0=A0=A0=A0=A0=A0=A0 * point math.=A0 We do so to have enough precision=
in the estimate
> -=A0=A0=A0=A0=A0=A0=A0 * and to avoid overflows.
> -=A0=A0=A0=A0=A0=A0=A0 */
> -=A0=A0=A0=A0=A0=A0=A0bw =3D (u64)bfqq->entity.service << BFQ_RATE_SHIFT;
> -=A0=A0=A0=A0=A0=A0=A0do_div(bw, (unsigned long)usecs);
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0delta_ktime =3D ktime_get()=
;
> +=A0=A0=A0=A0=A0=A0=A0delta_ktime =3D ktime_sub(delta_ktime, bfqd->last_b=
udget_start);
> +=A0=A0=A0=A0=A0=A0=A0delta_usecs =3D ktime_to_us(delta_ktime);
> +
This patch changes the type of the variable in which the result of ktime_to=
_us()
is stored from u64 into u32 and next compares that result with LONG_MAX. Si=
nce
ktime_to_us() returns a signed 64-bit number, are you sure you want to stor=
e that
result in a 32-bit variable? If ktime_to_us() would e.g. return 0xffffffff0=
0000100
or 0x100000100 then the assignment will truncate these numbers to 0x100.
Bart.=
WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "tj@kernel.org" <tj@kernel.org>,
"paolo.valente@linaro.org" <paolo.valente@linaro.org>,
"axboe@kernel.dk" <axboe@kernel.dk>
Cc: "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"fchecconi@gmail.com" <fchecconi@gmail.com>,
"avanzini.arianna@gmail.com" <avanzini.arianna@gmail.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: [PATCH V2 04/16] block, bfq: modify the peak-rate estimator
Date: Fri, 31 Mar 2017 15:31:44 +0000 [thread overview]
Message-ID: <1490974279.2587.5.camel@sandisk.com> (raw)
In-Reply-To: <20170331124743.3530-5-paolo.valente@linaro.org>
On Fri, 2017-03-31 at 14:47 +0200, Paolo Valente wrote:
> -static bool bfq_update_peak_rate(struct bfq_data *bfqd, struct bfq_queue *bfqq,
> - bool compensate)
> +static bool bfq_bfqq_is_slow(struct bfq_data *bfqd, struct bfq_queue *bfqq,
> + bool compensate, enum bfqq_expiration reason,
> + unsigned long *delta_ms)
> {
> - u64 bw, usecs, expected, timeout;
> - ktime_t delta;
> - int update = 0;
> + ktime_t delta_ktime;
> + u32 delta_usecs;
> + bool slow = BFQQ_SEEKY(bfqq); /* if delta too short, use seekyness */
>
> - if (!bfq_bfqq_sync(bfqq) || bfq_bfqq_budget_new(bfqq))
> + if (!bfq_bfqq_sync(bfqq))
> return false;
>
> if (compensate)
> - delta = bfqd->last_idling_start;
> + delta_ktime = bfqd->last_idling_start;
> else
> - delta = ktime_get();
> - delta = ktime_sub(delta, bfqd->last_budget_start);
> - usecs = ktime_to_us(delta);
> -
> - /* Don't trust short/unrealistic values. */
> - if (usecs < 100 || usecs >= LONG_MAX)
> - return false;
> -
> - /*
> - * Calculate the bandwidth for the last slice. We use a 64 bit
> - * value to store the peak rate, in sectors per usec in fixed
> - * point math. We do so to have enough precision in the estimate
> - * and to avoid overflows.
> - */
> - bw = (u64)bfqq->entity.service << BFQ_RATE_SHIFT;
> - do_div(bw, (unsigned long)usecs);
> + delta_ktime = ktime_get();
> + delta_ktime = ktime_sub(delta_ktime, bfqd->last_budget_start);
> + delta_usecs = ktime_to_us(delta_ktime);
> +
This patch changes the type of the variable in which the result of ktime_to_us()
is stored from u64 into u32 and next compares that result with LONG_MAX. Since
ktime_to_us() returns a signed 64-bit number, are you sure you want to store that
result in a 32-bit variable? If ktime_to_us() would e.g. return 0xffffffff00000100
or 0x100000100 then the assignment will truncate these numbers to 0x100.
Bart.
next prev parent reply other threads:[~2017-03-31 15:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 12:47 [PATCH V2 00/16] Introduce the BFQ I/O scheduler Paolo Valente
2017-03-31 12:47 ` [PATCH V2 01/16] block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler Paolo Valente
2017-03-31 12:47 ` [PATCH V2 02/16] block, bfq: add full hierarchical scheduling and cgroups support Paolo Valente
2017-03-31 12:47 ` [PATCH V2 03/16] block, bfq: improve throughput boosting Paolo Valente
2017-03-31 12:47 ` [PATCH V2 04/16] block, bfq: modify the peak-rate estimator Paolo Valente
2017-03-31 15:31 ` Bart Van Assche [this message]
2017-03-31 15:31 ` Bart Van Assche
2017-04-04 10:42 ` Paolo Valente
2017-04-04 10:42 ` Paolo Valente
2017-04-04 15:28 ` Bart Van Assche
2017-04-04 15:28 ` Bart Van Assche
2017-04-06 19:37 ` Paolo Valente
2017-04-06 19:37 ` Paolo Valente
2017-03-31 12:47 ` [PATCH V2 05/16] block, bfq: add more fairness with writes and slow processes Paolo Valente
2017-03-31 12:47 ` [PATCH V2 06/16] block, bfq: improve responsiveness Paolo Valente
2017-03-31 12:47 ` [PATCH V2 07/16] block, bfq: reduce I/O latency for soft real-time applications Paolo Valente
2017-03-31 12:47 ` [PATCH V2 08/16] block, bfq: preserve a low latency also with NCQ-capable drives Paolo Valente
2017-03-31 12:47 ` [PATCH V2 09/16] block, bfq: reduce latency during request-pool saturation Paolo Valente
2017-03-31 12:47 ` [PATCH V2 10/16] block, bfq: add Early Queue Merge (EQM) Paolo Valente
2017-03-31 12:47 ` [PATCH V2 11/16] block, bfq: reduce idling only in symmetric scenarios Paolo Valente
2017-03-31 15:20 ` Bart Van Assche
2017-03-31 15:20 ` Bart Van Assche
2017-04-07 7:47 ` Paolo Valente
2017-04-07 7:47 ` Paolo Valente
2017-03-31 12:47 ` [PATCH V2 12/16] block, bfq: boost the throughput on NCQ-capable flash-based devices Paolo Valente
2017-03-31 12:47 ` [PATCH V2 13/16] block, bfq: boost the throughput with random I/O on NCQ-capable HDDs Paolo Valente
2017-03-31 12:47 ` [PATCH V2 14/16] block, bfq: handle bursts of queue activations Paolo Valente
2017-03-31 12:47 ` [PATCH V2 15/16] block, bfq: remove all get and put of I/O contexts Paolo Valente
2017-03-31 12:47 ` [PATCH V2 16/16] block, bfq: split bfq-iosched.c into multiple source files Paolo Valente
2017-04-02 10:02 ` kbuild test robot
2017-04-11 11:00 ` Paolo Valente
2017-04-11 11:00 ` Paolo Valente
2017-04-12 8:39 ` [kbuild-all] " Ye Xiaolong
2017-04-12 9:24 ` Paolo Valente
2017-04-12 9:24 ` Paolo Valente
2017-04-12 16:05 ` Paolo Valente
2017-04-12 16:05 ` Paolo Valente
2017-04-10 16:56 ` [PATCH V2 00/16] Introduce the BFQ I/O scheduler Bart Van Assche
2017-04-10 16:56 ` Bart Van Assche
2017-04-11 8:43 ` Paolo Valente
2017-04-11 8:43 ` Paolo Valente
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1490974279.2587.5.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=avanzini.arianna@gmail.com \
--cc=axboe@kernel.dk \
--cc=broonie@kernel.org \
--cc=fchecconi@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paolo.valente@linaro.org \
--cc=tj@kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.