linux-kernel - [PATCH] mm/readahead.c: fix regression caused by small readahead limit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1440087598-27185-1-git-send-email-klamm@yandex-team.ru>
Date:	Thu, 20 Aug 2015 19:19:58 +0300
From:	Roman Gushchin <klamm@...dex-team.ru>
To:	linux-mm@...ck.org
Cc:	linux-kernel@...r.kernel.org,
	Roman Gushchin <klamm@...dex-team.ru>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>,
	Jan Kara <jack@...e.cz>, Wu Fengguang <fengguang.wu@...el.com>,
	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH] mm/readahead.c: fix regression caused by small readahead limit

Effectively reverts: 6d2be915e589b58cb11418cbe1f22ff90732b6ac
("mm/readahead.c: fix readahead failure for memoryless NUMA nodes and
limit readahead pages").

This commit causes significant i/o performance regression on large
RAID disks. Limiting maximal readahead size by 2Mb is not suitable for
this case, alghough previous logic (based on free memory size
on current NUMA node) is much better.

To avoid regression in case of memoryless NUMA we can still use
MAX_READAHEAD constant, if current node has no (or less) free memory.

before:

$ dd if=/dev/md2 of=/dev/null bs=100M count=100
100+0 records in
100+0 records out
10485760000 bytes (10 GB) copied, 12.6441 s, 829 MB/s

$ dd if=/dev/md2 of=/dev/null bs=100M count=100 iflag=direct
100+0 records in
100+0 records out
10485760000 bytes (10 GB) copied, 9.49377 s, 1.1 GB/s

after:

$ dd if=/dev/md2 of=/dev/null bs=100M count=100
100+0 records in
100+0 records out
10485760000 bytes (10 GB) copied, 9.18119 s, 1.1 GB/s

$ dd if=/dev/md2 of=/dev/null bs=100M count=100 iflag=direct
100+0 records in
100+0 records out
10485760000 bytes (10 GB) copied, 9.34751 s, 1.1 GB/s

(It's 8 disks RAID 5 with 1024k chunk.)

Signed-off-by: Roman Gushchin <klamm@...dex-team.ru>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Cc: Jan Kara <jack@...e.cz>
Cc: Wu Fengguang <fengguang.wu@...el.com>
Cc: David Rientjes <rientjes@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
---
 mm/readahead.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/mm/readahead.c b/mm/readahead.c
index 60cd846..93a00b3 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -239,7 +239,12 @@ int force_page_cache_readahead(struct address_space *mapping, struct file *filp,
  */
 unsigned long max_sane_readahead(unsigned long nr)
 {
-	return min(nr, MAX_READAHEAD);
+	unsigned long max_sane;
+
+	max_sane = max(MAX_READAHEAD,
+		       (node_page_state(numa_node_id(), NR_INACTIVE_FILE) +
+			node_page_state(numa_node_id(), NR_FREE_PAGES)) / 2);
+	return min(nr, max_sane);
 }
 
 /*
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/