[RFC] iosched: add cfq -> bfq alias

[RFC] iosched: add cfq -> bfq alias

[Xose Vazquez Perez]

Avoid break old scrips and udev rules.

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 95586137194e..8c6c82860a45 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -6914,6 +6914,7 @@ static struct elevator_type iosched_bfq_mq = {
  	.icq_align =		__alignof__(struct bfq_io_cq),
  	.elevator_attrs =	bfq_attrs,
  	.elevator_name =	"bfq",
+	.elevator_alias =	"cfq",
  	.elevator_owner =	THIS_MODULE,
  };
  MODULE_ALIAS("bfq-iosched");

Re: [RFC] iosched: add cfq -> bfq alias

[Oleksandr Natalenko]

Hi.

On Sat, Mar 06, 2021 at 11:46:31PM +0100, Xose Vazquez Perez wrote:
> 
> Avoid break old scrips and udev rules.
> 
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 95586137194e..8c6c82860a45 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -6914,6 +6914,7 @@ static struct elevator_type iosched_bfq_mq = {
>  	.icq_align =		__alignof__(struct bfq_io_cq),
>  	.elevator_attrs =	bfq_attrs,
>  	.elevator_name =	"bfq",
> +	.elevator_alias =	"cfq",
>  	.elevator_owner =	THIS_MODULE,
>  };
>  MODULE_ALIAS("bfq-iosched");

Hmmm NACK.

CFQ and BFQ are completely different beasts.

If you are going to tune BFQ to match old CFQ behaviour (somehow; I
don't know why one would do this, how one would do this and whether it
is possible at all), you for sure have enough time to fix your old udev
rules and scripts.

If you are just tolerating default BFQ behaviour, you should explicitly
acknowledge it by amending your rules and scripts. For personal systems
this is not a big deal. For enterprise systems you better do it NOW so
that another person that comes to work on those systems in 10 years
after you resign knows what and why was done.

If you are just lazy (no offence! I don't know your real intention
here), I'm not sure we are going to hide such an indifference behind
another aliasing kludge.

Thanks.

-- 
  Oleksandr Natalenko (post-factum)

Re: [RFC] iosched: add cfq -> bfq alias

[Xose Vazquez Perez]

On 3/7/21 8:26 PM, Oleksandr Natalenko wrote:

> Hmmm NACK.
> 
> CFQ and BFQ are completely different beasts.
> 
> If you are going to tune BFQ to match old CFQ behaviour (somehow; I
> don't know why one would do this, how one would do this and whether it
> is possible at all), you for sure have enough time to fix your old udev
> rules and scripts.
> 
> If you are just tolerating default BFQ behaviour, you should explicitly
> acknowledge it by amending your rules and scripts. For personal systems
> this is not a big deal. For enterprise systems you better do it NOW so
> that another person that comes to work on those systems in 10 years
> after you resign knows what and why was done.
> 
> If you are just lazy (no offence! I don't know your real intention
> here), I'm not sure we are going to hide such an indifference behind
> another aliasing kludge.
> 
> Thanks.
> 

You are writing a lot, and say nothing.

bfq is the natural choice coming from cfq. There is NO other option.

Still waiting... for a valid *technical* response against my change.

Or do you prefer to apply the below patch?.


---cortamorena---
 From 714f04d823085a1aebbdc66dad2344c2aee9fdf3 Mon Sep 17 00:00:00 2001
From: Xose Vazquez Perez <xose.vazquez@gmail.com>
Date: Wed, 24 Mar 2021 22:30:46 +0100
Subject: [PATCH] Revert "mq-deadline: add 'deadline' as a name alias"
X-Patchwork-Bot: notify

This reverts commit 4d740bc9f0319229410d11e445017f47e425dbe0.

_commit 4d740bc9f0319229410d11e445017f47e425dbe0
_Author: Jens Axboe <axboe@kernel.dk>
_Date:   Wed Oct 25 09:47:20 2017 -0600

     _mq-deadline: add 'deadline' as a name alias

     _The scheduler framework now supports looking up the appropriate
     _scheduler with the {name,mq} tupple. We can register mq-deadline
     _with the alias of 'deadline', so that switching to 'deadline'
     _will do the right thing based on the type of driver attached to
     _it.

     _Reviewed-by: Omar Sandoval <osandov@fb.com>
     _Signed-off-by: Jens Axboe <axboe@kernel.dk>

Cc: Jens Axboe <axboe@kernel.dk>
Cc: Omar Sandoval <osandov@fb.com>
Cc: Paolo Valente <paolo.valente@linaro.org>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: BLOCK ML <linux-block@vger.kernel.org>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
  block/mq-deadline.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/block/mq-deadline.c b/block/mq-deadline.c
index f3631a287466..91c9757451b3 100644
--- a/block/mq-deadline.c
+++ b/block/mq-deadline.c
@@ -795,7 +795,6 @@ static struct elevator_type mq_deadline = {
  #endif
  	.elevator_attrs = deadline_attrs,
  	.elevator_name = "mq-deadline",
-	.elevator_alias = "deadline",
  	.elevator_features = ELEVATOR_F_ZBD_SEQ_WRITE,
  	.elevator_owner = THIS_MODULE,
  };
-- 
2.30.2
---fin---


Thank you.

Re: [RFC] iosched: add cfq -> bfq alias

[Jens Axboe]

On 3/24/21 4:10 PM, Xose Vazquez Perez wrote:
> On 3/7/21 8:26 PM, Oleksandr Natalenko wrote:
> 
>> Hmmm NACK.
>>
>> CFQ and BFQ are completely different beasts.
>>
>> If you are going to tune BFQ to match old CFQ behaviour (somehow; I
>> don't know why one would do this, how one would do this and whether it
>> is possible at all), you for sure have enough time to fix your old udev
>> rules and scripts.
>>
>> If you are just tolerating default BFQ behaviour, you should explicitly
>> acknowledge it by amending your rules and scripts. For personal systems
>> this is not a big deal. For enterprise systems you better do it NOW so
>> that another person that comes to work on those systems in 10 years
>> after you resign knows what and why was done.
>>
>> If you are just lazy (no offence! I don't know your real intention
>> here), I'm not sure we are going to hide such an indifference behind
>> another aliasing kludge.
>>
>> Thanks.
>>
> 
> You are writing a lot, and say nothing.
> 
> bfq is the natural choice coming from cfq. There is NO other option.
> 
> Still waiting... for a valid *technical* response against my change.

Let's lay off the aggression a bit, it's not helpful.

They are two very different schedulers. Yes, they support some of the
same options, but they really have nothing in common outside of that. On
top of that, it's also very late to introduce a change like that, it
should've been done with the introduction of it.

> Or do you prefer to apply the below patch?.

Not a valid example, as mq-deadline and deadline are identical, one just
supports multiple queues.

-- 
Jens Axboe