ping
> Il giorno 9 ott 2019, alle ore 16:25, Paolo Valente
> ha scritto:
>
> Jens, Tejun,
> can we proceed with this double-interface solution?
>
> Thanks,
> Paolo
>
>> Il giorno 1 ott 2019, alle ore 21:33, Paolo Valente
>> ha scritto:
>>
>
Jens, Tejun,
can we proceed with this double-interface solution?
Thanks,
Paolo
> Il giorno 1 ott 2019, alle ore 21:33, Paolo Valente
> ha scritto:
>
> Hi Jens,
>
> the first patch in this series is Tejun's patch for making BFQ disable
> io.cost. The second patch
systemd/systemd/issues/7057
[2] https://lkml.org/lkml/2019/9/18/736
Suggested-by: Tejun Heo
Signed-off-by: Paolo Valente
---
Documentation/block/bfq-iosched.rst | 40 +++--
block/bfq-cgroup.c | 258 ++--
2 files changed, 153 insertions(+), 145 deletions(
checkpatch complains that these macros should be enclosed in
parentheses. I don't see how to do it. I'm willing to switch to any
better solution.
Thanks,
Paolo
[1] https://lkml.org/lkml/2019/9/18/736
Paolo Valente (1):
block, bfq: present a double cgroups interface
Tejun Heo (1):
blk
ly
re-enabled when bfq is built as a module and unloaded.
Signed-off-by: Tejun Heo
Cc: Paolo Valente
---
Documentation/admin-guide/cgroup-v2.rst | 8 ---
block/bfq-cgroup.c | 2 ++
block/bfq-iosched.c | 32 +
block/blk-ioc
> Il giorno 20 set 2019, alle ore 15:05, Jens Axboe ha
> scritto:
>
> On 9/20/19 12:58 AM, Paolo Valente wrote:
>>
>>
>>> Il giorno 18 set 2019, alle ore 18:19, Paolo Valente
>>> ha scritto:
>>>
>>>
>>>
&g
> Il giorno 18 set 2019, alle ore 18:19, Paolo Valente
> ha scritto:
>
>
>
>> Il giorno 18 set 2019, alle ore 17:19, Tejun Heo ha
>> scritto:
>>
>> Hello,
>>
>> On Wed, Sep 18, 2019 at 07:18:50AM +0200, Paolo Valente wrote:
>
> Il giorno 18 set 2019, alle ore 17:19, Tejun Heo ha scritto:
>
> Hello,
>
> On Wed, Sep 18, 2019 at 07:18:50AM +0200, Paolo Valente wrote:
>> A solution that both fulfills userspace request and doesn't break
>> anything for hypothetical users of the current
> Il giorno 17 set 2019, alle ore 23:32, Tejun Heo ha scritto:
>
> Hello,
>
> On Tue, Sep 17, 2019 at 06:51:48PM +0200, Paolo Valente wrote:
>> When bfq was merged into mainline, there were two I/O schedulers that
>> implemented the proportional-share policy:
any longer for
these prefixes in (the never used) bfq names. In view of this fact, this
commit removes these prefixes, thereby enabling legacy code to truly
use the proportional share policy in blk-mq.
[1] https://github.com/systemd/systemd/issues/7057
Signed-off-by: Angelo Ruocco
Signed-off-by: Paolo
ly
re-enabled when bfq is built as a module and unloaded.
Signed-off-by: Tejun Heo
Cc: Paolo Valente
---
Documentation/admin-guide/cgroup-v2.rst | 8 ---
block/bfq-cgroup.c | 2 ++
block/bfq-iosched.c | 32 +
block/blk-ioc
Hi Jens,
here is the pair of patches from [1] and [2].
Thanks,
Paolo
[1] https://lkml.org/lkml/2019/9/16/469
[2]
https://lore.kernel.org/linux-block/20190917151334.gi3084...@devbig004.ftw2.facebook.com/
Angelo Ruocco (1):
block, bfq: delete "bfq" prefix from cgroup filenames
Tejun Heo (1):
> Il giorno 16 set 2019, alle ore 18:01, Jens Axboe ha
> scritto:
>
> On 9/16/19 9:21 AM, Paolo Valente wrote:
>>
>>
>>> Il giorno 16 set 2019, alle ore 17:16, Tejun Heo ha
>>> scritto:
>>>
>>> Hello, Paolo.
>>&g
Hi Jens,
can these be considered for 5.4 too?
Thanks,
Paolo
> Il giorno 9 set 2019, alle ore 08:03, Oleksandr Natalenko
> ha scritto:
>
> On 22.08.2019 17:20, Paolo Valente wrote:
>> Hi Jens,
>> this patch series makes the injection mechanism better at preserving
>
> Il giorno 16 set 2019, alle ore 17:16, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Mon, Sep 16, 2019 at 05:07:29PM +0200, Paolo Valente wrote:
>> Tejun, could you put your switch-off-io-cost code into a standalone
>> patch, so that I can put it together
> Il giorno 16 set 2019, alle ore 17:01, Jens Axboe ha
> scritto:
>
> On 9/16/19 8:56 AM, Paolo Valente wrote:
>> News of this change? Can we have it (or the solution with the
>> symlinks if you prefer it) for 5.4?
>
> Coordinate with Tejun and bundle the st
News of this change? Can we have it (or the solution with the
symlinks if you prefer it) for 5.4?
Thanks,
Paolo
> Il giorno 9 set 2019, alle ore 09:31, Paolo Valente
> ha scritto:
>
> Hi Jens,
> now that BFQ's weight interface has been fixed [1], can we proceed
> wi
> Il giorno 11 set 2019, alle ore 16:16, Tejun Heo ha scritto:
>
> Hello,
>
> On Wed, Sep 11, 2019 at 10:18:53AM +0200, Paolo Valente wrote:
>>> The two being enabled at the same time doesn't make sense, so we can
>>> just switch over to bfq when bf
> Il giorno 10 set 2019, alle ore 18:08, Tejun Heo ha scritto:
>
> Hello, Michal.
>
> On Tue, Sep 10, 2019 at 02:55:14PM +0200, Michal Koutný wrote:
>> This adds the generic io.weight attribute. How will this compose with
>> the weight from IO schedulers? (AFAIK, only BFQ allows proportional
Hi Jens,
now that BFQ's weight interface has been fixed [1], can we proceed
with this change?
In addition to acking this solution, in [2] Tejun already suggested a
reduced version of the present patch. In Tejun's version, only
bfq.weight is changed. But I guess that legacy code may use also some
o
any longer for
these prefixes in (the never used) bfq names. In view of this fact, this
commit removes these prefixes, thereby enabling legacy code to truly
use the proportional share policy in blk-mq.
[1] https://github.com/systemd/systemd/issues/7057
Signed-off-by: Angelo Ruocco
Signed-off-by: Paolo
Hi Jens,
have you looked into this?
Thanks,
Paolo
> Il giorno 22 ago 2019, alle ore 17:20, Paolo Valente
> ha scritto:
>
> Hi Jens,
> this patch series makes the injection mechanism better at preserving
> control on I/O.
>
> Thanks,
> Paolo
>
> Paolo V
Hi Jens,
is this patch series fine now?
Thanks,
Paolo
> Il giorno 28 ago 2019, alle ore 05:54, Fam Zheng
> ha scritto:
>
> v3: Pick up rev-by and ack-by from Paolo and Tejun.
>Add commit message to patch 3.
>
> (Revision starting from v2 since v1 was used off-list)
>
> Hi Paolo and other
> Il giorno 5 set 2019, alle ore 18:55, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> So, I'm currently verifying iocost in the FB fleet. Around three
> thousand machines running v5.2 (+ some backports) with btrfs on a
> handful of different models of consumer grade SSDs. I haven't seen
> com
> Il giorno 2 set 2019, alle ore 17:56, Tejun Heo ha scritto:
>
> On Mon, Sep 02, 2019 at 05:45:50PM +0200, Paolo Valente wrote:
>> Thanks for this extra explanations. It is a little bit difficult for
>> me to understand how the min/max teaks for exactly, but you did g
> Il giorno 31 ago 2019, alle ore 08:53, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
Hi Tejun,
> On Thu, Aug 22, 2019 at 10:58:22AM +0200, Paolo Valente wrote:
>> Ok, I tried with the parameters reported for a SATA SSD:
>>
>> rpct=95.00 rlat=1 wpct=95.0
go [1]?
Thanks,
Paolo
[1] https://lkml.org/lkml/2019/8/29/910
> Il giorno 31 ago 2019, alle ore 08:53, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Thu, Aug 22, 2019 at 10:58:22AM +0200, Paolo Valente wrote:
>> Ok, I tried with the parameters reported for a SATA SSD:
>>
Hi,
I see an important interface problem. Userspace has been waiting for
io.weight to become eventually the file name for setting the weight
for the proportional-share policy [1,2]. If you use that name, how
will we solve this?
Thanks,
Paolo
[1] https://github.com/systemd/systemd/issues/7057#is
Hi Jens,
do you think this series could now be queued for 5.4?
Thanks,
Paolo
> Il giorno 21 ago 2019, alle ore 17:44, Tejun Heo ha scritto:
>
> On Mon, Aug 05, 2019 at 02:38:07PM +0800, Fam Zheng wrote:
>> Signed-off-by: Fam Zheng
>
> Looks good to me.
>
> Acked-by: Tejun Heo
>
> Thanks.
>
Hi Jens,
this patch series makes the injection mechanism better at preserving
control on I/O.
Thanks,
Paolo
Paolo Valente (4):
block, bfq: update inject limit only after injection occurred
block, bfq: reduce upper bound for inject limit to max_rq_in_driver+1
block, bfq: increase update
case. This commit fixes this issue.
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index ddac93e910fa..0319d6339822 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq
to 10 ms.
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index e114282204f6..ddac93e910fa 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2016,7 +2016,7 @@ static
unfinished I/O may delay the service of rq);
- injection occurs between the arrival and the completion time of rq.
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
then cause max_rq_in_driver itself
to grow.
However, since the limit is incremented by only one unit at a time,
there is no need for such a high bound, and just max_rq_in_driver+1 is
enough.
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
> Il giorno 20 ago 2019, alle ore 17:19, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Tue, Aug 20, 2019 at 05:04:25PM +0200, Paolo Valente wrote:
>> and makes one fio instance generate I/O for each group. The bandwidth
>> reported above is that reported by the
> Il giorno 20 ago 2019, alle ore 12:48, Paolo Valente
> ha scritto:
>
>
>
>> Il giorno 14 giu 2019, alle ore 19:56, Tejun Heo ha
>> scritto:
>>
>> On Thu, Jun 13, 2019 at 06:56:10PM -0700, Tejun Heo wrote:
>> ...
>>> The
> Il giorno 14 giu 2019, alle ore 19:56, Tejun Heo ha scritto:
>
> On Thu, Jun 13, 2019 at 06:56:10PM -0700, Tejun Heo wrote:
> ...
>> The patchset is also available in the following git branch.
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-iow
>
> Updated patchset
> Il giorno 14 giu 2019, alle ore 23:05, Paolo Valente
> ha scritto:
>
>
>
>> Il giorno 14 giu 2019, alle ore 22:22, Tejun Heo ha
>> scritto:
>>
>> Hello,
>>
>> On Thu, Jun 13, 2019 at 08:10:38AM +0200, Paolo Valente wrote:
>&
> Il giorno 19 ago 2019, alle ore 18:40, Marc MERLIN ha
> scritto:
>
> On Mon, Aug 19, 2019 at 11:18:13AM +0200, Paolo Valente wrote:
>> Solving this kind of problem is one of the goals of the BFQ I/O scheduler
>> [1].
>> Have you tried? If you want to, th
> Il giorno 19 ago 2019, alle ore 18:41, Paolo Valente
> ha scritto:
>
>
>
>> Il giorno 16 ago 2019, alle ore 20:17, Paolo Valente
>> ha scritto:
>>
>>
>>
>>> Il giorno 16 ago 2019, alle ore 19:59, Josef Bacik
>>> ha sc
> Il giorno 16 ago 2019, alle ore 20:17, Paolo Valente
> ha scritto:
>
>
>
>> Il giorno 16 ago 2019, alle ore 19:59, Josef Bacik ha
>> scritto:
>>
>> On Fri, Aug 16, 2019 at 07:52:40PM +0200, Paolo Valente wrote:
>>>
>>>
> Il giorno 19 ago 2019, alle ore 11:18, Paolo Valente
> ha scritto:
>
>
>
>> Il giorno 19 ago 2019, alle ore 09:08, Marc MERLIN ha
>> scritto:
>>
>> (Please Cc me on replies so that I can see them more quickly)
>>
>> Dear Block Fol
> Il giorno 19 ago 2019, alle ore 09:08, Marc MERLIN ha
> scritto:
>
> (Please Cc me on replies so that I can see them more quickly)
>
> Dear Block Folks,
>
Hi Marc,
> I just inherited a Dell 2950 with a Perc 5/i.
> I really don't want to use that Perc 5/i card, but from all the reading
>
> Il giorno 16 ago 2019, alle ore 19:59, Josef Bacik ha
> scritto:
>
> On Fri, Aug 16, 2019 at 07:52:40PM +0200, Paolo Valente wrote:
>>
>>
>>> Il giorno 16 ago 2019, alle ore 15:21, Josef Bacik
>>> ha scritto:
>>>
>>> O
> Il giorno 16 ago 2019, alle ore 15:21, Josef Bacik ha
> scritto:
>
> On Fri, Aug 16, 2019 at 12:57:41PM +0200, Paolo Valente wrote:
>> Hi,
>> I happened to test the io.latency controller, to make a comparison
>> between this controller and BFQ. But io.lat
ted-by: Hsin-Yi Wang
Cc: Hsin-Yi Wang
Cc: Nicolas Boichat
Cc: Doug Anderson
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 586fcfe227ea..32686300d89b 100
Hi Jens,
this is a hopefully complete version of the fix proposed by Guenter [1].
Thanks,
Paolo
[1] https://lkml.org/lkml/2019/7/22/824
Paolo Valente (1):
block, bfq: handle NULL return value by bfq_init_rq()
block/bfq-iosched.c | 14 +++---
1 file changed, 11 insertions(+), 3
a857a4c4e8 ("block, bfq: detect wakers and unconditionally inject
their I/O")
Reported-by: Douglas Anderson
Tested-by: Douglas Anderson
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/block/bfq-iosched.c b
akers and unconditionally inject
their I/O")
Reported-by: Douglas Anderson
Tested-by: Douglas Anderson
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 44 +---
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/block/bfq-iosched
#c57
Paolo Valente (2):
block, bfq: reset last_completed_rq_bfqq if the pointed queue is freed
block, bfq: move update of waker and woken list to queue freeing
block/bfq-iosched.c | 54 ++---
1 file changed, 36 insertions(+), 18 deletions(-)
--
2.20.1
Hi,
I hope this has to do with the failure reported by Doug. I'm
finalizing my fix. I'd appreciate if you could retry with my fix
applied.
Thanks,
Paolo
> Il giorno 7 ago 2019, alle ore 12:10, Pavel Machek ha scritto:
>
> Hi!
>
> Machine is thinkpad x220. BFQ related?
>
>
>
> [ 8224
Thank you very much, Fam, for this extension.
Reviewed-by: Paolo Valente
> Il giorno 5 ago 2019, alle ore 08:38, Fam Zheng
> ha scritto:
>
> (Revision starting from v2 since v1 was used off-list)
>
> Hi Paolo and others,
>
> This adds to BFQ the missing per-
> Il giorno 30 lug 2019, alle ore 15:35, Guenter Roeck ha
> scritto:
>
> On 7/30/19 1:55 AM, Paolo Valente wrote:
>> Hi Guenter,
>> sorry for the delay (Dolomiti's fault).
>> I didn't consider that rq->elv-icq might have been NULL also
>>
Hi Guenter,
sorry for the delay (Dolomiti's fault).
I didn't consider that rq->elv-icq might have been NULL also
because of OOM. Thanks for spotting this issue.
As for the other places where the return value of bfq_init_rq is used,
unfortunately I think they matter too. Those other places are r
idling only in symmetric
scenarios")
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 67 +
1 file changed, 43 insertions(+), 24 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 72860325245a..586fcfe227ea 100644
-
hanks,
Paolo
Paolo Valente (1):
block, bfq: check also in-flight I/O in dispatch plugging
block/bfq-iosched.c | 67 +
1 file changed, 43 insertions(+), 24 deletions(-)
--
2.20.1
> Il giorno 16 lug 2019, alle ore 16:11, Jens Axboe ha
> scritto:
>
> On 7/15/19 4:57 AM, Paolo Valente wrote:
>> [V2 that should apply cleanly on current HEAD]
>>
>> Hi Jens,
>> I've spotted a regression on a fast SSD: a loss of I/O-latency contr
970 PRO,
gnome-terminal starts in 1.5 seconds after this fix, against 15
seconds before the fix (as a reference, gnome-terminal takes about 35
seconds to start with any of the other I/O schedulers).
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 67 +-
r 5.3.
Thanks,
Paolo
Paolo Valente (1):
block, bfq: check also in-flight I/O in dispatch plugging
block/bfq-iosched.c | 67 +
1 file changed, 43 insertions(+), 24 deletions(-)
--
2.20.1
Ops, my fault of course. I submitted the patch I made on top of the dev version
of bfq. Preparing a V2. Sorry.
> Il giorno 15 lug 2019, alle ore 12:49, Holger Hoffstätte
> ha scritto:
>
> On 7/15/19 12:18 PM, Paolo Valente wrote:
>> Didn't I simply move it forward
Didn't I simply move it forward in that commit?
> Il giorno 15 lug 2019, alle ore 12:16, Holger Hoffstätte
> ha scritto:
>
>
> Paolo,
>
> The function idling_needed_for_service_guarantees() was just removed in
> 5.3-commit
> 3726112ec731 ("block, bfq: re-schedule empty queues if they deserve
970 PRO,
gnome-terminal starts in 1.5 seconds after this fix, against 15
seconds before the fix (as a reference, gnome-terminal takes about 35
seconds to start with any of the other I/O schedulers).
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 67 +-
Hi Jens,
I've spotted a regression on a fast SSD: a loss of I/O-latency control
with interactive tasks (such as the application start up I usually
test). Details in the commit.
I do hope that, after proper review, this commit makes it for 5.3.
Thanks,
Paolo
Paolo Valente (1):
block
). Despite all these delays, some
>> extra debugging showed that all the hoops could be jumped through in
>> time and the memory could be freed causing the original crash. Phew!
>>
>> To make a long story short, assuming it truly is illegal to access an
>> icq after the
ught forward dramatically, for it is
not blocked for milliseconds.
Reported-by: Srivatsa S. Bhat (VMware)
Tested-by: Srivatsa S. Bhat (VMware)
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 270 ++--
block/bfq-iosched.h | 25 +++-
2 files
s from 15.1 to 3.2 ms for
a process doing sporadic random reads while another process is doing
continuous sequential reads.
Signed-off-by: Nicola Bottura
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 95 +++--
1 file changed, 75 insertions(+), 20 d
)
Tested-by: Srivatsa S. Bhat (VMware)
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 62442083b147..d5bc32371ace 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq
0 with 1 in the
comparison.
Reported-by: Srivatsa S. Bhat (VMware)
Tested-by: Srivatsa S. Bhat (VMware)
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 9bc
-by: Srivatsa S. Bhat (VMware)
Tested-by: Srivatsa S. Bhat (VMware)
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 05041f84b8da..62442083b147 100644
--- a/block
t both for bfqq and for the total throughput, as explained
in detail in the comments in bfq_update_has_short_ttime().
Reported-by: Srivatsa S. Bhat (VMware)
Tested-by: Srivatsa S. Bhat (VMware)
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 219 ++
s service
guarantees.
This commit addresses this issue by re-scheduling Q even if it is
empty. This in turn breaks the assumption that all scheduled queues
are non empty. Then a few extra checks are now needed.
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 387 +++
loss of control over I/O bandwidths
Thanks,
Paolo
[1] https://lkml.org/lkml/2019/5/17/755
Paolo Valente (7):
block, bfq: reset inject limit when think-time state changes
block, bfq: fix rq_in_driver check in bfq_update_inject_limit
block, bfq: update base request service times when possible
> Il giorno 24 giu 2019, alle ore 22:15, Srivatsa S. Bhat
> ha scritto:
>
> On 6/24/19 12:40 PM, Paolo Valente wrote:
>> Hi Jens,
>> this series, based against for-5.3/block, contains:
>> 1) The improvements to recover the throughput loss reported by
>>
s from 15.1 to 3.2 ms for
a process doing sporadic random reads while another process is doing
continuous sequential reads.
Signed-off-by: Nicola Bottura
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 95 +++--
1 file changed, 75 insertions(+), 20 d
s service
guarantees.
This commit addresses this issue by re-scheduling Q even if it is
empty. This in turn breaks the assumption that all scheduled queues
are non empty. Then a few extra checks are now needed.
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 387 +++
ught forward dramatically, for it is
not blocked for milliseconds.
Tested-by: Srivatsa S. Bhat
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 270 ++--
block/bfq-iosched.h | 25 +++-
2 files changed, 261 insertions(+), 34 deletions(-)
diff --git
0 with 1 in the
comparison.
Tested-by: Srivatsa S. Bhat
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 9bc10198ddff..05041f84b8da 100644
--- a/block/bfq-iosched.c
++
-by: Paolo Valente
---
block/bfq-iosched.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 62442083b147..d5bc32371ace 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -4979,19 +4979,9 @@ static void
] https://lkml.org/lkml/2019/5/17/755
Paolo Valente (7):
block, bfq: reset inject limit when think-time state changes
block, bfq: fix rq_in_driver check in bfq_update_inject_limit
block, bfq: update base request service times when possible
block, bfq: bring forward seek&think time up
t both for bfqq and for the total throughput, as explained
in detail in the comments in bfq_update_has_short_ttime().
Tested-by: Srivatsa S. Bhat
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 219 ++--
1 file changed, 151 insertions(+), 68 deletion
: Srivatsa S. Bhat
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 05041f84b8da..62442083b147 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -5496,7
> Il giorno 24 giu 2019, alle ore 18:12, Jens Axboe ha
> scritto:
>
> On 6/22/19 2:44 PM, Paolo Valente wrote:
>> By mistake, there is a '&' instead of a '==' in the definition of the
>> macro BFQQ_TOTALLY_SEEKY. This commit replaces the wr
By mistake, there is a '&' instead of a '==' in the definition of the
macro BFQQ_TOTALLY_SEEKY. This commit replaces the wrong operator with
the correct one.
Fixes: commit 7074f076ff15 ("block, bfq: do not tag totally seeky queues as
soft rt")
Signed-off
Sorry, I forgot to mention the fixed commit. Making a V2 ...
> Il giorno 22 giu 2019, alle ore 21:38, Paolo Valente
> ha scritto:
>
> By mistake, there is a '&' instead of a '==' in the definition of the
> macro BFQQ_TOTALLY_SEEKY. This commit replaces th
Hi Jens,
any chance this trivial, but rather critical fix makes it into 5.2?
Thanks,
Paolo
Paolo Valente (1):
block, bfq: fix operator in BFQQ_TOTALLY_SEEKY
block/bfq-iosched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.20.1
By mistake, there is a '&' instead of a '==' in the definition of the
macro BFQQ_TOTALLY_SEEKY. This commit replaces the wrong operator with
the correct one.
Signed-off-by: Paolo Valente
---
block/bfq-iosched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
> Il giorno 14 giu 2019, alle ore 22:22, Tejun Heo ha scritto:
>
> Hello,
>
> On Thu, Jun 13, 2019 at 08:10:38AM +0200, Paolo Valente wrote:
>> BFQ does not implement weight_device, but we are not talking about
>> weight_device here. More precisely, *nothing* impl
> Il giorno 12 giu 2019, alle ore 15:39, Tejun Heo ha scritto:
>
> On Wed, Jun 12, 2019 at 09:32:07AM +0200, Paolo Valente wrote:
>> Could you elaborate a little more on this?
>
> Doesn't seem like you did.
>
>> bfq code for setting up and handling io.weig
> Il giorno 12 giu 2019, alle ore 00:34, Srivatsa S. Bhat
> ha scritto:
>
> On 6/2/19 12:04 AM, Srivatsa S. Bhat wrote:
>> On 5/30/19 3:45 AM, Paolo Valente wrote:
>>>
> [...]
>>> At any rate, since you pointed out that you are interested in
>>
> Il giorno 11 giu 2019, alle ore 23:17, Tejun Heo ha scritto:
>
> On Tue, Jun 11, 2019 at 12:49:59PM -0700, Tejun Heo wrote:
>> (Description mostly stolen from 19e9da9e86c4 ("block, bfq: add weight
>> symlink to the bfq.weight cgroup parameter")
>>
>> Many userspace tools and services use the
> Il giorno 10 giu 2019, alle ore 12:15, Jens Axboe ha
> scritto:
>
> On 6/9/19 10:06 AM, Linus Torvalds wrote:
>> On Sat, Jun 8, 2019 at 11:00 PM Jens Axboe wrote:
>>>
>>> FWIW, the concept/idea goes back a few months and was discussed with
>>> the cgroup folks. But I totally agree that the
ping
> Il giorno 30 mag 2019, alle ore 17:02, Paolo Valente
> ha scritto:
>
> Hi Jens,
> have you had time to look into this?
>
> Thanks,
> Paolo
>
>> Il giorno 21 mag 2019, alle ore 10:01, Paolo Valente
>> ha scritto:
>>
>> Many user
> Il giorno 6 giu 2019, alle ore 12:26, Christoph Hellwig ha
> scritto:
>
> This function was moved from core block code and is way to generic.
> Fold it into the only caller and simplify it based on the actually
> passed arguments.
>
Acked-by: Paolo Valente
>
> Il giorno 6 giu 2019, alle ore 12:26, Christoph Hellwig ha
> scritto:
>
> This option is entirely bfq specific, give it an appropinquate name.
>
> Also make it depend on CONFIG_BFQ_GROUP_IOSCHED in Kconfig, as all
> the functionality already does so anyway.
>
> Il giorno 6 giu 2019, alle ore 12:26, Christoph Hellwig ha
> scritto:
>
> This structure and assorted infrastructure is only used by the bfq I/O
> scheduler. Move it there instead of bloating the common code.
>
Acked-by: Paolo Valente
> Signed-off-by: Christoph H
Hi Jens,
have you had time to look into this?
Thanks,
Paolo
> Il giorno 21 mag 2019, alle ore 10:01, Paolo Valente
> ha scritto:
>
> Many userspace tools and services use the proportional-share policy of
> the blkio/io cgroups controller. The CFQ I/O scheduler implemented
&g
> Il giorno 30 mag 2019, alle ore 10:29, Srivatsa S. Bhat
> ha scritto:
>
> On 5/29/19 12:41 AM, Paolo Valente wrote:
>>
>>
>>> Il giorno 29 mag 2019, alle ore 03:09, Srivatsa S. Bhat
>>> ha scritto:
>>>
>>> On 5/23/19 11:5
> Il giorno 29 mag 2019, alle ore 03:09, Srivatsa S. Bhat
> ha scritto:
>
> On 5/23/19 11:51 PM, Paolo Valente wrote:
>>
>>> Il giorno 24 mag 2019, alle ore 01:43, Srivatsa S. Bhat
>>> ha scritto:
>>>
>>> When trying to run multip
> Il giorno 24 mag 2019, alle ore 16:46, Jeff Moyer ha
> scritto:
>
> Hi, Alexey,
>
> Alexey Dobriyan writes:
>
>> 5.0 deleted three io schedulers and more importantly CONFIG_DEFAULT_IOSCHED
>> option:
>>
>> commit f382fb0bcef4c37dc049e9f6963e3baf204d815c
>> block: remove legacy
> Il giorno 24 mag 2019, alle ore 08:51, Paolo Valente
> ha scritto:
>
>
>
>> Il giorno 24 mag 2019, alle ore 01:43, Srivatsa S. Bhat
>> ha scritto:
>>
>> On 5/23/19 10:22 AM, Paolo Valente wrote:
>>>
>>>> Il giorno
1 - 100 of 724 matches
Mail list logo
