search for: device_offlin

...ks 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 -- Thanks, David / d...

...ks 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....

...ks 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....

...es. 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 <mhocko at suse.com&gt...

...es. 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 <mhocko at suse.com&gt...

...es. 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: David Hildenbrand <d...

...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/2020030214273...

...) 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 &lt...

...nt 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 meantime. + */ + if (!rc && try_remove_memory(nid, start, size)) +...

.... try_remove_memory would > fail if the range is offline (via user interface) but there are still some > pages in the driver Offline state? try_remove_memory() does not check any memmap (because it is garbage), it only makes sure that the memory blocks are properly marked as offline. (IOW, device_offline() was called on the memory block). > >> Once offline, the memmap is irrelevant and try_remove_memory() can do its >> job. >> >>> Do we really have hook into __put_page? Why do we even care about the >>> reference count of those pages? Wouldn't it be jus...

On Wed 16-10-19 14:50:30, David Hildenbrand wrote: > On 16.10.19 13:43, Michal Hocko wrote: > > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > > > virtio-mem wants to allow to offline memory blocks of which some parts > > > were unplugged, especially, to later offline and remove completely > > > unplugged memory blocks. The important part is that

On Wed 16-10-19 14:50:30, David Hildenbrand wrote: > On 16.10.19 13:43, Michal Hocko wrote: > > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > > > virtio-mem wants to allow to offline memory blocks of which some parts > > > were unplugged, especially, to later offline and remove completely > > > unplugged memory blocks. The important part is that

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 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

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