@@ -41,7 +41,7 @@ MODULE_PARM_DESC(bbm_block_size,
static bool bbm_safe_unplug = true;
module_param(bbm_safe_unplug, bool, 0444);
MODULE_PARM_DESC(bbm_safe_unplug,
- "Use a safe unplug mechanism in BBM, avoiding long/endless loops");
+ "Use a safe/fast unplug mechanism in BBM, failing faster on unmovable pages");
/*
* virtio-mem currently supports the following modes of operation:
@@ -738,7 +738,7 @@ static int virtio_mem_offline_and_remove_memory(struct virtio_mem *vm,
"offlining and removing memory: 0x%llx - 0x%llx\n", addr,
addr + size - 1);
- rc = offline_and_remove_memory(addr, size, 0);
+ rc = offline_and_remove_memory(addr, size, 10 * MSEC_PER_SEC);
if (!rc) {
atomic64_sub(size, &vm->offline_size);
/*
Currently we use the default (30 seconds), let's reduce it to 10 seconds. In BBM, we barely deal with blocks larger than 1/2 GiB, and after 10 seconds it's most probably best to give up on that memory block and try another one (or retry this one later). In the common fake-offline case where we effectively fake-offline memory using alloc_contig_range() first (SBM or BBM with bbm_safe_unplug=on), we expect offline_and_remove_memory() to be blazingly fast and never take anywhere close to 10seconds -- so this should only affect BBM with bbm_safe_unplug=off. While at it, update the parameter description and the relationship to unmovable pages. Signed-off-by: David Hildenbrand <david@redhat.com> --- drivers/virtio/virtio_mem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)