Qu Wenruo 845cf1c769 btrfs: do not wait for short bulk allocation
commit 1db7959aacd905e6487d0478ac01d89f86eb1e51 upstream.

[BUG]
There is a recent report that when memory pressure is high (including
cached pages), btrfs can spend most of its time on memory allocation in
btrfs_alloc_page_array() for compressed read/write.

[CAUSE]
For btrfs_alloc_page_array() we always go alloc_pages_bulk_array(), and
even if the bulk allocation failed (fell back to single page
allocation) we still retry but with extra memalloc_retry_wait().

If the bulk alloc only returned one page a time, we would spend a lot of
time on the retry wait.

The behavior was introduced in commit 395cb57e8560 ("btrfs: wait between
incomplete batch memory allocations").

[FIX]
Although the commit mentioned that other filesystems do the wait, it's
not the case at least nowadays.

All the mainlined filesystems only call memalloc_retry_wait() if they
failed to allocate any page (not only for bulk allocation).
If there is any progress, they won't call memalloc_retry_wait() at all.

For example, xfs_buf_alloc_pages() would only call memalloc_retry_wait()
if there is no allocation progress at all, and the call is not for
metadata readahead.

So I don't believe we should call memalloc_retry_wait() unconditionally
for short allocation.

Call memalloc_retry_wait() if it fails to allocate any page for tree
block allocation (which goes with __GFP_NOFAIL and may not need the
special handling anyway), and reduce the latency for
btrfs_alloc_page_array().

Reported-by: Julian Taylor <julian.taylor@1und1.de>
Tested-by: Julian Taylor <julian.taylor@1und1.de>
Link: https://lore.kernel.org/all/8966c095-cbe7-4d22-9784-a647d1bf27c3@1und1.de/
Fixes: 395cb57e8560 ("btrfs: wait between incomplete batch memory allocations")
CC: stable@vger.kernel.org # 6.1+
Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-17 12:02:39 +02:00
..
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-28 11:39:14 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-28 09:31:32 -07:00
2023-08-28 11:04:18 -07:00
2023-08-28 10:17:14 -07:00
2024-04-03 15:28:32 +02:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 17:45:22 -04:00
2023-08-29 20:21:42 -07:00
2023-08-31 12:07:34 -05:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
\n
2023-08-30 12:10:50 -07:00
2023-08-29 20:21:42 -07:00
2024-02-23 09:25:13 +01:00
2023-08-28 10:17:14 -07:00
2023-06-28 20:35:21 -07:00
2023-06-26 09:50:21 -07:00
2023-07-26 14:56:07 +02:00
2024-03-26 18:19:17 -04:00
2023-08-08 19:36:51 +02:00
2023-08-28 10:17:14 -07:00
2023-08-21 13:46:25 -07:00
2023-08-14 18:48:02 +02:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-19 12:12:12 +02:00
2023-08-31 15:32:18 -07:00
2023-08-02 09:13:09 -06:00
2023-07-13 10:28:04 +02:00
2023-08-15 08:32:45 +02:00
2023-08-31 12:47:15 +02:00