From 7779ed6d3b4ca27f3c5320d13d5872b93bb9dde3 Mon Sep 17 00:00:00 2001 From: Mike Snitzer Date: Wed, 24 Aug 2011 18:13:27 -0400 Subject: [CRAZY RFC PATCH 2/4] dm: increase RESERVED_REQUEST_BASED_IOS The old value of 256 could handle cloning a 1024k request that was composed entirely of 4K bios. 256 never accounted for a real-world worst case where max_hw_sectors_kb is say 32768 or 65536 and the user has adjusted max_sectors_kb to match. Now that request-based DM's mempools are shared their reserves should be increased. So I drew a arbitrary line in the sand to accomodate a max_hw_sectors_kb of 32768 (32 MB) and then multiplied by 2. Multiplying by 2 effectively admits that using shared mempools will always be problematic in extremely low memory conditions. Devices will be fighting for the finite supply of IOs the mempools provide. Not-Signed-off-by: Mike Snitzer --- drivers/md/dm.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/md/dm.c b/drivers/md/dm.c index d04fe17..d904dd8 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -200,7 +200,15 @@ struct dm_md_mempools { }; #define RESERVED_BIO_BASED_IOS 16 -#define RESERVED_REQUEST_BASED_IOS 256 +/* + * Request-based DM uses shared mempools to reduce the slab footprint. + * RESERVED_REQUEST_BASED_IOS reflects the ability to clone a request + * with bios that address a worst-case max_hw_sectors of 32 MB. + * + * Multiply by 2 for adding padding because the mempools are shared. + * But there is no one size fits all here... + */ +#define RESERVED_REQUEST_BASED_IOS (8192 * 2) static struct kmem_cache *_io_cache; static struct kmem_cache *_tio_cache; -- 1.7.1