Displaying 20 results from an estimated 2000 matches similar to: "[PATCH v2 0/7] mm/memory_hotplug: selective merging of system ram resources"
2020 Sep 11
13
[PATCH v4 0/8] selective merging of system ram resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where
2020 Sep 11
13
[PATCH v4 0/8] selective merging of system ram resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where
2020 Sep 10
9
[PATCH v3 0/7] mm/memory_hotplug: selective merging of system ram resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where
2020 Apr 29
4
[PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools
This series is based on [1]:
[PATCH v2 00/10] virtio-mem: paravirtualized memory
That will hopefull get picked up soon, rebased to -next.
The following patches were reverted from -next [2]:
[PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use
As discussed in that thread, they should be reverted from -next already.
In theory, if people agree, we could take the first two patches
2020 Jul 31
6
[PATCH RFCv1 0/5] mm/memory_hotplug: selective merging of memory resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where
2020 Aug 21
8
[PATCH v1 0/5] mm/memory_hotplug: selective merging of system ram resources
This is the follow-up of "[PATCH RFCv1 0/5] mm/memory_hotplug: selective
merging of memory resources" [1]
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant
2020 Apr 30
5
[PATCH v2 0/3] mm/memory_hotplug: Allow to not create firmware memmap entries
This is the follow up of [1]:
[PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with
kexec-tools
I realized that this is not only helpful for virtio-mem, but also for
dax/kmem - it's a fix for that use case (see patch #3) of persistent
memory.
Also, while testing, I discovered that kexec-tools will *not* add dax/kmem
memory (anything not directly under the root when parsing
2020 Apr 30
2
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
On 29.04.20 18:08, David Hildenbrand wrote:
> Some paravirtualized devices that add memory via add_memory() and
> friends (esp. virtio-mem) don't want to create entries in
> /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> memory to the boot memmap of the kexec kernel.
>
> In fact, such memory is never exposed via the firmware (e.g., e820), but
> only
2020 Apr 30
2
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
On 29.04.20 18:08, David Hildenbrand wrote:
> Some paravirtualized devices that add memory via add_memory() and
> friends (esp. virtio-mem) don't want to create entries in
> /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> memory to the boot memmap of the kexec kernel.
>
> In fact, such memory is never exposed via the firmware (e.g., e820), but
> only
2020 Jun 11
2
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
Virtio-mem managed memory is always detected and added by the virtio-mem
driver, never using something like the firmware-provided memory map.
This is the case after an ordinary system reboot, and has to be guaranteed
after kexec. Especially, virtio-mem added memory resources can contain
inaccessible parts ("unblocked memory blocks"), blindly forwarding them
to a kexec kernel is
2020 Jun 11
2
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
Virtio-mem managed memory is always detected and added by the virtio-mem
driver, never using something like the firmware-provided memory map.
This is the case after an ordinary system reboot, and has to be guaranteed
after kexec. Especially, virtio-mem added memory resources can contain
inaccessible parts ("unblocked memory blocks"), blindly forwarding them
to a kexec kernel is
2020 Sep 08
0
[PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalvador at suse.de
Acked-by: Wei Liu <wei.liu at kernel.org>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Michal Hocko <mhocko at suse.com>
Cc: Dan Williams
2020 Sep 10
0
[PATCH v3 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalvador at suse.de
Acked-by: Wei Liu <wei.liu at kernel.org>
Reviewed-by: Juergen Gross <jgross at suse.com> # Xen related part
Cc: Andrew Morton <akpm at
2010 Aug 12
13
[PATCH] GSoC 2010 - Memory hotplug support for Xen guests - third fully working version
Hi,
Here is the third version of memory hotplug support
for Xen guests patch. This one cleanly applies to
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
repository, xen/memory-hotplug head.
On Fri, Aug 06, 2010 at 04:03:18PM +0400, Vasiliy G Tolstov wrote:
[...]
> Testing on sles 11 sp1 and opensuse 11.3. On results - send e-mail..
Thx.
On Fri, Aug 06, 2010 at 12:34:08PM
2020 Sep 11
1
[PATCH v3 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
Hi David,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200909]
[cannot apply to mmotm/master hnaz-linux-mm/master xen-tip/linux-next powerpc/next linus/master v5.9-rc4 v5.9-rc3 v5.9-rc2 v5.9-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
2020 May 07
20
[PATCH v3 00/15] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v3
Patch #1 - #10 where contained in v2 and only contain minor modifications
(mostly smaller fixes). The remaining patches are new and contain smaller
optimizations.
Details about virtio-mem can be found in the cover letter of v2 [1]. A
basic QEMU implementation was
2020 May 07
20
[PATCH v3 00/15] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v3
Patch #1 - #10 where contained in v2 and only contain minor modifications
(mostly smaller fixes). The remaining patches are new and contain smaller
optimizations.
Details about virtio-mem can be found in the cover letter of v2 [1]. A
basic QEMU implementation was
2010 Aug 06
5
[PATCH] GSoC 2010 - Memory hotplug support for Xen guests - second fully working version - once again
Hi,
I am sending this e-mail once again because it probably
has been lost in abyss of Xen-devel/LKLM list.
Here is the second version of memory hotplug support
for Xen guests patch. This one cleanly applies to
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
repository, xen/memory-hotplug head.
Changes:
- /sys/devices/system/memory/probe interface has been removed;
2020 Mar 11
12
[PATCH v2 00/10] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v2
I now have acks for all !virtio-mem changes. I'll be happy to get review
feedback, testing reports, etc. for the virtio-mem changes. If there are
no further comments, I guess this is good to go as a v1 soon.
The basic idea of virtio-mem is to provide a
2020 May 07
17
[PATCH v4 00/15] virtio-mem: paravirtualized memory
This series is based on v5.7-rc4. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v4
This is basically a resend of v3 [1], now based on v5.7-rc4 and restested.
One patch was reshuffled and two ACKs I missed to add were added. The
rebase did not require any modifications to patches.
Details about virtio-mem can be found in the cover letter of v2 [2]. A