Re: [PATCH v1 2/3] mm/memory_hotplug: initialize memmap of !ZONE_DEVICE with PageOffline() instead of PageReserved()

On Tue, 11 Jun 2024 11:42:56 +0200 David Hildenbrand wrote: > > We'll leave the ZONE_DEVICE case alone for now. > > > > @Andrew, can we add here: > > "Note that self-hosted vmemmap pages will no longer be marked as > reserved. This matches ordinary vmemmap pages allocated from the buddy >

Re: [PATCH v1 1/3] mm: pass meminit_context to __free_pages_core()

On Tue, 11 Jun 2024 12:06:56 +0200 David Hildenbrand wrote: > On 07.06.24 11:09, David Hildenbrand wrote: > > In preparation for further changes, let's teach __free_pages_core() > > about the differences of memory hotplug handling. > > > > Move the memory hotplug specific handling from

Re: [PATCH v2] mm, page_alloc: fix build_zonerefs_node()

On Thu, 7 Apr 2022 14:06:37 +0200 Juergen Gross wrote: > Since commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim from > zones with pages managed by the buddy allocator") Six years ago! > only zones with free > memory are included in a built zonelist. This is problematic when e.g. >

Re: remove alloc_vm_area v2

On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > this series removes alloc_vm_area, which was left over from the big > vmalloc interface rework. It is a rather arkane interface, basicaly > the equivalent of get_vm_area + actually faulting in all PTEs in > the allocated area. It

Re: [PATCH v4 1/2] memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC

On Tue, 11 Aug 2020 11:44:46 +0200 Roger Pau Monne wrote: > This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also > being used by non DAX devices. Acked-by: Andrew Morton . Please add it to the Xen tree when appropriate. (I'm not sure what David means by "se

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand wrote: > > > > Why does the firmware map support hotplug entries? > > I assume: > > The firmware memmap was added primarily for x86-64 kexec (and still, is > mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs > get

Re: [Xen-devel] [PATCH v2 0/8] mm/kdump: allow to exclude pages that are logically offline

On Wed, 27 Feb 2019 13:32:14 +0800 Dave Young wrote: > This series have been in -next for some days, could we get this in > mainline? It's been in -next for two months? > Andrew, do you have plan about them, maybe next release? They're all reviewed except for "xen/balloon: mark inflated

Re: [Xen-devel] [PATCH v5 1/2] memory_hotplug: Free pages as higher order

On Mon, 05 Nov 2018 15:12:27 +0530 Arun KS wrote: > On 2018-10-22 16:03, Arun KS wrote: > > On 2018-10-19 13:37, Michal Hocko wrote: > >> On Thu 18-10-18 19:18:25, Andrew Morton wrote: > >> [...] > >>> So this patch needs more work, yes? > >> &g

Re: [Xen-devel] [PATCH v5 1/2] memory_hotplug: Free pages as higher order

On Thu, 11 Oct 2018 09:55:03 +0200 Michal Hocko wrote: > > > > > This is now not called anymore, although the xen/hv variants still do > > > > > it. The function seems empty these days, maybe remove it as a followup > > > > > cleanup? > > > > > > > > > > > -

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote: > On Fri 20-07-18 17:09:02, Andrew Morton wrote: > [...] > > - Undocumented return value. > > > > - comment "failed to reap part..." is misleading - sounds like it's > > referring to somethin

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote: > From: Michal Hocko > > There are several blockable mmu notifiers which might sleep in > mmu_notifier_invalidate_range_start and that is a problem for the > oom_reaper because it needs to guarantee a forward progress so it cannot > depend

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote: > > Any suggestions regarding how the driver developers can test this code > > path? I don't think we presently have a way to fake an oom-killing > > event? Perhaps we should add such a thing, given the problems we're > > having with that

Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote: > From: Michal Hocko > > There are several blockable mmu notifiers which might sleep in > mmu_notifier_invalidate_range_start and that is a problem for the > oom_reaper because it needs to guarantee a forward progress so it cannot > depend

Re: [Xen-devel] [PATCH] mm: don't defer struct page initialization for Xen pv guests

declaration of function > >> 'xen_pv_domain' [-Werror=implicit-function-declaration] > if (xen_pv_domain()) > ^ I think I already fixed this. From: Andrew Morton <a...@linux-foundation.org> Subject: mm-dont-defer-struct-page-initialization-fo

Re: [Xen-devel] [RESEND v2] mm: don't defer struct page initialization for Xen pv guests

On Fri, 16 Feb 2018 16:41:01 +0100 Juergen Gross wrote: > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -347,6 +347,9 @@ static inline bool update_defer_init(pg_data_t *pgdat, > /* Always populate low zones for address-constrained allocations */ > if (zone_end <

Re: [Xen-devel] [RESEND v2] mm: don't defer struct page initialization for Xen pv guests

On Fri, 16 Feb 2018 16:41:01 +0100 Juergen Gross wrote: > Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing > memory during allocation in vmemmap") broke Xen pv domains in some > configurations, as the "Pinned" information in struct page of early > page tables