Re: max_queued_requests for raid1 and raid10 - questions
From: NeilBrown <hidden>
Date: 2021-06-29 10:37:01
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