Commit aedcd72f authored Sep 17, 2014 by Jens Axboe

blk-mq: limit memory consumption if a crash dump is active



It's not uncommon for crash dump kernels to be limited to 128MB or
something low in that area. This is normally not a problem for
devices as we don't use that much memory, but for some shared SCSI
setups with huge queue depths, it can potentially fill most of
memory with tons of request allocations. blk-mq does scale back
when it fails to allocate memory, but it scales back just enough
so that blk-mq succeeds. This could still leave the system with
not enough memory to make any real progress.

Check if we are in a kdump environment and limit the hardware
queues and tag depth.

Signed-off-by: Jens Axboe <axboe@fb.com>

parent 2edd2c74

block/blk-mq.c

+11 −0

Original line number	Diff line number	Diff line
		@@ -20,6 +20,7 @@
		#include <linux/cache.h>
		#include <linux/sched/sysctl.h>
		#include <linux/delay.h>
		#include <linux/crash_dump.h>

		#include <trace/events/block.h>

		@@ -1742,6 +1743,16 @@ struct request_queue blk_mq_init_queue(struct blk_mq_tag_set set)
		if (!ctx)
		return ERR_PTR(-ENOMEM);

		/*
		* If a crashdump is active, then we are potentially in a very
		* memory constrained environment. Limit us to 1 queue and
		* 64 tags to prevent using too much memory.
		*/
		if (is_kdump_kernel()) {
		set->nr_hw_queues = 1;
		set->queue_depth = min(64U, set->queue_depth);
		}

		hctxs = kmalloc_node(set->nr_hw_queues * sizeof(*hctxs), GFP_KERNEL,
		set->numa_node);