search for: find_memory_block

...l unplugged > subblocks are PageOffline() and have a reference count of 0 - so > offlining code will simply skip them. > > All we need is an interface to offline and remove the memory from kernel > module context, where we don't have access to the memory block devices > (esp. find_memory_block() and device_offline()) and the device hotplug > lock. > > To keep things simple, allow to only work on a single memory block. > Lost the ACK from Michael Acked-by: Michal Hocko <mhocko at suse.com> [1] [1] https://lkml.kernel.org/r/20200302142737.GP4380 at dhcp22.suse.cz --...

...l unplugged > subblocks are PageOffline() and have a reference count of 0 - so > offlining code will simply skip them. > > All we need is an interface to offline and remove the memory from kernel > module context, where we don't have access to the memory block devices > (esp. find_memory_block() and device_offline()) and the device hotplug > lock. > > To keep things simple, allow to only work on a single memory block. > > Acked-by: Michal Hocko <mhocko at suse.com> > Tested-by: Pankaj Gupta <pankaj.gupta.linux at gmail.com> > Cc: Andrew Morton <akpm...

...l unplugged > subblocks are PageOffline() and have a reference count of 0 - so > offlining code will simply skip them. > > All we need is an interface to offline and remove the memory from kernel > module context, where we don't have access to the memory block devices > (esp. find_memory_block() and device_offline()) and the device hotplug > lock. > > To keep things simple, allow to only work on a single memory block. > > Acked-by: Michal Hocko <mhocko at suse.com> > Tested-by: Pankaj Gupta <pankaj.gupta.linux at gmail.com> > Cc: Andrew Morton <akpm...

...quire to migrate any pages. All unplugged subblocks are PageOffline() and have a reference count of 0 - so offlining code will simply skip them. All we need is an interface to offline and remove the memory from kernel module context, where we don't have access to the memory block devices (esp. find_memory_block() and device_offline()) and the device hotplug lock. To keep things simple, allow to only work on a single memory block. Cc: Andrew Morton <akpm at linux-foundation.org> Cc: David Hildenbrand <david at redhat.com> Cc: Oscar Salvador <osalvador at suse.com> Cc: Michal Hocko <m...

...quire to migrate any pages. All unplugged subblocks are PageOffline() and have a reference count of 0 - so offlining code will simply skip them. All we need is an interface to offline and remove the memory from kernel module context, where we don't have access to the memory block devices (esp. find_memory_block() and device_offline()) and the device hotplug lock. To keep things simple, allow to only work on a single memory block. Cc: Andrew Morton <akpm at linux-foundation.org> Cc: David Hildenbrand <david at redhat.com> Cc: Oscar Salvador <osalvador at suse.com> Cc: Michal Hocko <m...

...quire to migrate any pages. All unplugged subblocks are PageOffline() and have a reference count of 0 - so offlining code will simply skip them. All we need is an interface to offline and remove the memory from kernel module context, where we don't have access to the memory block devices (esp. find_memory_block() and device_offline()) and the device hotplug lock. To keep things simple, allow to only work on a single memory block. Acked-by: Michal Hocko <mhocko at suse.com> Tested-by: Pankaj Gupta <pankaj.gupta.linux at gmail.com> Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Dav...

...ON() in remove_memory() if there would have been a race). > Can drop that part. > > > > > Or is still mostly about not requiring callers to open code this general > > patter? > > From kernel module context, I cannot get access to the actual memory > block device (find_memory_block()) and call the device_unregister(). > > Especially, also the device hotplug lock is not exported. So this is a > clean helper function to be used from kernel module context. (e.g., also > hyper-v showed interest for using that) Fair enough. -- Michal Hocko SUSE Labs

...s are PageOffline() and have a reference count of 0 - so > > offlining code will simply skip them. > > > > All we need is an interface to offline and remove the memory from kernel > > module context, where we don't have access to the memory block devices > > (esp. find_memory_block() and device_offline()) and the device hotplug > > lock. > > > > To keep things simple, allow to only work on a single memory block. > > > > Lost the ACK from Michael > > Acked-by: Michal Hocko <mhocko at suse.com> [1] > > [1] https://lkml.kernel...

...bblocks are PageOffline() and have a reference count of 0 - so >> offlining code will simply skip them. >> >> All we need is an interface to offline and remove the memory from kernel >> module context, where we don't have access to the memory block devices >> (esp. find_memory_block() and device_offline()) and the device hotplug >> lock. >> >> To keep things simple, allow to only work on a single memory block. >> >> Acked-by: Michal Hocko <mhocko at suse.com> >> Tested-by: Pankaj Gupta <pankaj.gupta.linux at gmail.com> >> C...

...offline + remove the memory block. + */ +int offline_and_remove_memory(int nid, u64 start, u64 size) +{ + struct memory_block *mem; + int rc = -EINVAL; + + if (!IS_ALIGNED(start, memory_block_size_bytes()) || + size != memory_block_size_bytes()) + return rc; + + lock_device_hotplug(); + mem = find_memory_block(__pfn_to_section(PFN_DOWN(start))); + if (mem) + rc = device_offline(&mem->dev); + /* Ignore if the device is already offline. */ + if (rc > 0) + rc = 0; + + /* + * In case we succeeded to offline the memory block, remove it. + * This cannot fail as it cannot get onlined in the meanti...

...); + + if (ret) { + pr_err("%s: online_pages: Failed: %i\n", __func__, ret); + goto error; + } + + pfn = PFN_DOWN(balloon_stats.hotplug_start_paddr); + pfn_limit = pfn + (balloon_stats.hotplug_size >> PAGE_SHIFT); + + for (; pfn < pfn_limit; pfn += PAGES_PER_SECTION) { + mem = find_memory_block(__pfn_to_section(pfn)); + BUG_ON(!mem); + BUG_ON(!present_section_nr(mem->phys_index)); + mutex_lock(&mem->state_mutex); + mem->state = MEM_ONLINE; + mutex_unlock(&mem->state_mutex); + } + + goto out; + +error: + balloon_stats.current_pages -= balloon_stats.hotplug_size &gt...

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

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

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

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v1 The basic idea of virtio-mem is to provide a flexible, cross-architecture memory hot(un)plug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found below and in linked material. It's

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v1 The basic idea of virtio-mem is to provide a flexible, cross-architecture memory hot(un)plug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found below and in linked material. It's

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

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-rfc-v4 The basic idea of virtio-mem is to provide a flexible, cross-architecture memory hot(un)plug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found below and in linked material. This

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-rfc-v4 The basic idea of virtio-mem is to provide a flexible, cross-architecture memory hot(un)plug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found below and in linked material. This

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