max_queued_requests for raid1 and raid10 - questions

max_queued_requests for raid1 and raid10 - questions

[Tkaczyk, Mariusz]

Hello Neil,
I have some questions related to max_queued_requests implemented by you
for raid1 and raid10. See code below:

/* When there are this many requests queue to be written by
  * the raid thread, we become 'congested' to provide back-pressure
  * for writeback.
  */
static int max_queued_requests = 1024;


It was added years ago:
https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/commit
/?id=34db0cd60f8a1f4ab73d118a8be3797c20388223

I've reached out scenario with cache in write-only mode where
this limiter degrades performance significantly (around 4 times).
I used Open-CAS:
https://github.com/Open-CAS/open-cas-linux

So, at this point I have some basic questions:
Is "back-pressure" still a case? Do you know any scenario where it
brings benefits?
If yes, I'll move this parameter to sysfs, to make it configurable
via mdadm config file (using SYSFS line) per array.
What do you think?

 From other hand, shall be consider to bump this value up? It seems to
be small today.

TIA,
Mariusz

Fwd: max_queued_requests for raid1 and raid10 - questions

[Tkaczyk, Mariusz]

Hello,
Sorry for noise, missclick.

Mariusz


-------- Forwarded Message --------
Subject: max_queued_requests for raid1 and raid10 - questions
Date: Tue, 29 Jun 2021 10:37:58 +0200
From: Tkaczyk, Mariusz <mariusz.tkaczyk@linux.intel.com>
To: NeilBrown <neilb@suse.com>

Hello Neil,
I have some questions related to max_queued_requests implemented by you
for raid1 and raid10. See code below:

/* When there are this many requests queue to be written by
  * the raid thread, we become 'congested' to provide back-pressure
  * for writeback.
  */
static int max_queued_requests = 1024;


It was added years ago:
https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/commit
/?id=34db0cd60f8a1f4ab73d118a8be3797c20388223

I've reached out scenario with cache in write-only mode where
this limiter degrades performance significantly (around 4 times).
I used Open-CAS:
https://github.com/Open-CAS/open-cas-linux

So, at this point I have some basic questions:
Is "back-pressure" still a case? Do you know any scenario where it
brings benefits?
If yes, I'll move this parameter to sysfs, to make it configurable
via mdadm config file (using SYSFS line) per array.
What do you think?

 From other hand, shall be consider to bump this value up? It seems to
be small today.

TIA,
Mariusz

Re: max_queued_requests for raid1 and raid10 - questions

[NeilBrown]

On Tue, 29 Jun 2021, Tkaczyk, Mariusz wrote:
> 
> Hello Neil,
> I have some questions related to max_queued_requests implemented by you
> for raid1 and raid10. See code below:
> 
> /* When there are this many requests queue to be written by
>   * the raid thread, we become 'congested' to provide back-pressure
>   * for writeback.
>   */
> static int max_queued_requests = 1024;
> 
> 
> It was added years ago:
> https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/commit
> /?id=34db0cd60f8a1f4ab73d118a8be3797c20388223
> 
> I've reached out scenario with cache in write-only mode where
> this limiter degrades performance significantly (around 4 times).
> I used Open-CAS:
> https://github.com/Open-CAS/open-cas-linux
> 
> So, at this point I have some basic questions:
> Is "back-pressure" still a case? Do you know any scenario where it
> brings benefits?

As you say, it was years ago.  Things have probably changed.

At the time, the mm system would write to a device until it got marked
"congested".  If there wasn't some sort of limit on the device queue
size, you would end up with an enormous queue that would take a long
time to flush and so high-priority reads would get stuck behind
low-priority writes and weird things like that.

The writeback now has a much more sophisticated approach, measuring the
actually throughput of each device and adjusting writes accordingly.

> If yes, I'll move this parameter to sysfs, to make it configurable
> via mdadm config file (using SYSFS line) per array.
> What do you think?
> 
>  From other hand, shall be consider to bump this value up? It seems to
> be small today.

I suspect that the best thing to do would be to remove the limit
completely.
Certainly that is the first thing I would try.  Try removing the limit,
but monitor the count of queued requests and see if something else stops
it from consuming all memory.

NeilBrown