/removing
> heterogeneous/device memory, we should always hold the mem_hotplug_lock in
> write mode to serialise memory hotplug (e.g. access to global/zone
> -variables).
> +variables). Currently, we take advantage of this to serialise sparsemem's
> +mem_section handling in sparse_add_one_
On 05.12.18 03:34, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
>
> Generally speaking, we leverage the two global lock:
>
> * device_hotplug_lock
> * mem_hotplug_lock
>
> to serialise the process.
>
> While for the long term, we are willing to have more
so code accessing memory can protect from that memory
> -vanishing.
> -
> -
> Future Work
> ===
>
>
I reported this yesterday to Jonathan and Mike
https://lkml.org/lkml/2018/12/3/340
Anyhow
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
>
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 50ce1bddaf56..f91da3d0a67e 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -670,7 +670,7 @@ PAGEFLAG_FALSE(DoubleMap)
> #define PAGE_TYPE_BASE 0xf000
> /* Reserve
y allocation (KVM_CAP_USER_MEMORY) is
> -available.
> +The new VM has no virtual cpus and no memory.
Reviewed-by: David Hildenbrand <da...@redhat.com>
--
Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@v
