All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Reale <ar@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	m.bielski@virtualopensystems.com, arunks@qti.qualcomm.com,
	mark.rutland@arm.com, scott.branden@broadcom.com,
	will.deacon@arm.com, qiuxishi@huawei.com,
	catalin.marinas@arm.com, realean2@ie.ibm.com
Subject: Re: [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem
Date: Mon, 4 Dec 2017 11:49:09 +0000	[thread overview]
Message-ID: <20171204114908.GC6373@samekh> (raw)
In-Reply-To: <20171130145134.el3qq7pr3q4xqglz@dhcp22.suse.cz>

On Thu 30 Nov 2017, 15:51, Michal Hocko wrote:
> On Thu 23-11-17 11:14:38, Andrea Reale wrote:
> > When hot-removing memory we need to free vmemmap memory.
> > However, depending on the memory is being removed, it might
> > not be always possible to free a full vmemmap page / huge-page
> > because part of it might still be used.
> > 
> > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables
> > hot-remove") introduced a workaround for x86
> > hot-remove, by which partially unused areas are filled with
> > the 0xFD constant. Full pages are only removed when fully
> > filled by 0xFDs.
> > 
> > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with
> > the goal of using it in place of 0xFDs. For now, this will be used for
> > the arm64 port of memory hot remove, but the idea is to eventually use
> > the same mechanism for x86 as well.
> 
> Why cannot you use the same approach as x86 have? Have a look at the
> vmemmap_free at al.
> 

This arm64 hot-remove version (including vmemmap_free) is indeed an
almost 1-to-1 port of the x86 approach. 

If you look at the first version of the patchset we submitted a while 
ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the
x86 approach of filling unsued page structs with 0xFDs. Commenting on
that, Mark suggested (and, indeed, I agree with him) that relying on a
magic constant for marking some portions of physical memory was quite
ugly. That is why we have used memblock for the purpose in this revised
patchset.

If you have a different view and any concrete suggestion on how to
improve this, it is definitely very well welcome. 

> > Signed-off-by: Andrea Reale <ar@linux.vnet.ibm.com>
> > Signed-off-by: Maciej Bielski <m.bielski@virtualopensystems.com>
> > ---
> >  include/linux/memblock.h | 12 ++++++++++++
> >  mm/memblock.c            | 32 ++++++++++++++++++++++++++++++++
> >  2 files changed, 44 insertions(+)
> > 
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index bae11c7..0daec05 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -26,6 +26,9 @@ enum {
> >  	MEMBLOCK_HOTPLUG	= 0x1,	/* hotpluggable region */
> >  	MEMBLOCK_MIRROR		= 0x2,	/* mirrored region */
> >  	MEMBLOCK_NOMAP		= 0x4,	/* don't add to kernel direct mapping */
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +	MEMBLOCK_UNUSED_VMEMMAP	= 0x8,  /* Mark VMEMAP blocks as dirty */
> > +#endif
> >  };
> >  
> >  struct memblock_region {
> > @@ -90,6 +93,10 @@ int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
> >  int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
> >  int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
> >  ulong choose_memblock_flags(void);
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +int memblock_mark_unused_vmemmap(phys_addr_t base, phys_addr_t size);
> > +int memblock_clear_unused_vmemmap(phys_addr_t base, phys_addr_t size);
> > +#endif
> >  
> >  /* Low level functions */
> >  int memblock_add_range(struct memblock_type *type,
> > @@ -182,6 +189,11 @@ static inline bool memblock_is_nomap(struct memblock_region *m)
> >  	return m->flags & MEMBLOCK_NOMAP;
> >  }
> >  
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +bool memblock_is_vmemmap_unused_range(struct memblock_type *mt,
> > +		phys_addr_t start, phys_addr_t end);
> > +#endif
> > +
> >  #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> >  int memblock_search_pfn_nid(unsigned long pfn, unsigned long *start_pfn,
> >  			    unsigned long  *end_pfn);
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 9120578..30d5aa4 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -809,6 +809,18 @@ int __init_memblock memblock_clear_nomap(phys_addr_t base, phys_addr_t size)
> >  	return memblock_setclr_flag(base, size, 0, MEMBLOCK_NOMAP);
> >  }
> >  
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +int __init_memblock memblock_mark_unused_vmemmap(phys_addr_t base,
> > +		phys_addr_t size)
> > +{
> > +	return memblock_setclr_flag(base, size, 1, MEMBLOCK_UNUSED_VMEMMAP);
> > +}
> > +int __init_memblock memblock_clear_unused_vmemmap(phys_addr_t base,
> > +		phys_addr_t size)
> > +{
> > +	return memblock_setclr_flag(base, size, 0, MEMBLOCK_UNUSED_VMEMMAP);
> > +}
> > +#endif
> >  /**
> >   * __next_reserved_mem_region - next function for for_each_reserved_region()
> >   * @idx: pointer to u64 loop variable
> > @@ -1696,6 +1708,26 @@ void __init_memblock memblock_trim_memory(phys_addr_t align)
> >  	}
> >  }
> >  
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +bool __init_memblock memblock_is_vmemmap_unused_range(struct memblock_type *mt,
> > +		phys_addr_t start, phys_addr_t end)
> > +{
> > +	u64 i;
> > +	struct memblock_region *r;
> > +
> > +	i = memblock_search(mt, start);
> > +	r = &(mt->regions[i]);
> > +	while (r->base < end) {
> > +		if (!(r->flags & MEMBLOCK_UNUSED_VMEMMAP))
> > +			return 0;
> > +
> > +		r = &(memblock.memory.regions[++i]);
> > +	}
> > +
> > +	return 1;
> > +}
> > +#endif
> > +
> >  void __init_memblock memblock_set_current_limit(phys_addr_t limit)
> >  {
> >  	memblock.current_limit = limit;
> > -- 
> > 2.7.4
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Thanks,
Andrea

> 
> -- 
> Michal Hocko
> SUSE Labs
> 

WARNING: multiple messages have this Message-ID (diff)
From: Andrea Reale <ar@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	m.bielski@virtualopensystems.com, arunks@qti.qualcomm.com,
	mark.rutland@arm.com, scott.branden@broadcom.com,
	will.deacon@arm.com, qiuxishi@huawei.com,
	catalin.marinas@arm.com, realean2@ie.ibm.com
Subject: Re: [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem
Date: Mon, 4 Dec 2017 11:49:09 +0000	[thread overview]
Message-ID: <20171204114908.GC6373@samekh> (raw)
In-Reply-To: <20171130145134.el3qq7pr3q4xqglz@dhcp22.suse.cz>

On Thu 30 Nov 2017, 15:51, Michal Hocko wrote:
> On Thu 23-11-17 11:14:38, Andrea Reale wrote:
> > When hot-removing memory we need to free vmemmap memory.
> > However, depending on the memory is being removed, it might
> > not be always possible to free a full vmemmap page / huge-page
> > because part of it might still be used.
> > 
> > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables
> > hot-remove") introduced a workaround for x86
> > hot-remove, by which partially unused areas are filled with
> > the 0xFD constant. Full pages are only removed when fully
> > filled by 0xFDs.
> > 
> > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with
> > the goal of using it in place of 0xFDs. For now, this will be used for
> > the arm64 port of memory hot remove, but the idea is to eventually use
> > the same mechanism for x86 as well.
> 
> Why cannot you use the same approach as x86 have? Have a look at the
> vmemmap_free at al.
> 

This arm64 hot-remove version (including vmemmap_free) is indeed an
almost 1-to-1 port of the x86 approach. 

If you look at the first version of the patchset we submitted a while 
ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the
x86 approach of filling unsued page structs with 0xFDs. Commenting on
that, Mark suggested (and, indeed, I agree with him) that relying on a
magic constant for marking some portions of physical memory was quite
ugly. That is why we have used memblock for the purpose in this revised
patchset.

If you have a different view and any concrete suggestion on how to
improve this, it is definitely very well welcome. 

> > Signed-off-by: Andrea Reale <ar@linux.vnet.ibm.com>
> > Signed-off-by: Maciej Bielski <m.bielski@virtualopensystems.com>
> > ---
> >  include/linux/memblock.h | 12 ++++++++++++
> >  mm/memblock.c            | 32 ++++++++++++++++++++++++++++++++
> >  2 files changed, 44 insertions(+)
> > 
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index bae11c7..0daec05 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -26,6 +26,9 @@ enum {
> >  	MEMBLOCK_HOTPLUG	= 0x1,	/* hotpluggable region */
> >  	MEMBLOCK_MIRROR		= 0x2,	/* mirrored region */
> >  	MEMBLOCK_NOMAP		= 0x4,	/* don't add to kernel direct mapping */
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +	MEMBLOCK_UNUSED_VMEMMAP	= 0x8,  /* Mark VMEMAP blocks as dirty */
> > +#endif
> >  };
> >  
> >  struct memblock_region {
> > @@ -90,6 +93,10 @@ int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
> >  int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
> >  int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
> >  ulong choose_memblock_flags(void);
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +int memblock_mark_unused_vmemmap(phys_addr_t base, phys_addr_t size);
> > +int memblock_clear_unused_vmemmap(phys_addr_t base, phys_addr_t size);
> > +#endif
> >  
> >  /* Low level functions */
> >  int memblock_add_range(struct memblock_type *type,
> > @@ -182,6 +189,11 @@ static inline bool memblock_is_nomap(struct memblock_region *m)
> >  	return m->flags & MEMBLOCK_NOMAP;
> >  }
> >  
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +bool memblock_is_vmemmap_unused_range(struct memblock_type *mt,
> > +		phys_addr_t start, phys_addr_t end);
> > +#endif
> > +
> >  #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> >  int memblock_search_pfn_nid(unsigned long pfn, unsigned long *start_pfn,
> >  			    unsigned long  *end_pfn);
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 9120578..30d5aa4 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -809,6 +809,18 @@ int __init_memblock memblock_clear_nomap(phys_addr_t base, phys_addr_t size)
> >  	return memblock_setclr_flag(base, size, 0, MEMBLOCK_NOMAP);
> >  }
> >  
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +int __init_memblock memblock_mark_unused_vmemmap(phys_addr_t base,
> > +		phys_addr_t size)
> > +{
> > +	return memblock_setclr_flag(base, size, 1, MEMBLOCK_UNUSED_VMEMMAP);
> > +}
> > +int __init_memblock memblock_clear_unused_vmemmap(phys_addr_t base,
> > +		phys_addr_t size)
> > +{
> > +	return memblock_setclr_flag(base, size, 0, MEMBLOCK_UNUSED_VMEMMAP);
> > +}
> > +#endif
> >  /**
> >   * __next_reserved_mem_region - next function for for_each_reserved_region()
> >   * @idx: pointer to u64 loop variable
> > @@ -1696,6 +1708,26 @@ void __init_memblock memblock_trim_memory(phys_addr_t align)
> >  	}
> >  }
> >  
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +bool __init_memblock memblock_is_vmemmap_unused_range(struct memblock_type *mt,
> > +		phys_addr_t start, phys_addr_t end)
> > +{
> > +	u64 i;
> > +	struct memblock_region *r;
> > +
> > +	i = memblock_search(mt, start);
> > +	r = &(mt->regions[i]);
> > +	while (r->base < end) {
> > +		if (!(r->flags & MEMBLOCK_UNUSED_VMEMMAP))
> > +			return 0;
> > +
> > +		r = &(memblock.memory.regions[++i]);
> > +	}
> > +
> > +	return 1;
> > +}
> > +#endif
> > +
> >  void __init_memblock memblock_set_current_limit(phys_addr_t limit)
> >  {
> >  	memblock.current_limit = limit;
> > -- 
> > 2.7.4
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Thanks,
Andrea

> 
> -- 
> Michal Hocko
> SUSE Labs
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: ar@linux.vnet.ibm.com (Andrea Reale)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem
Date: Mon, 4 Dec 2017 11:49:09 +0000	[thread overview]
Message-ID: <20171204114908.GC6373@samekh> (raw)
In-Reply-To: <20171130145134.el3qq7pr3q4xqglz@dhcp22.suse.cz>

On Thu 30 Nov 2017, 15:51, Michal Hocko wrote:
> On Thu 23-11-17 11:14:38, Andrea Reale wrote:
> > When hot-removing memory we need to free vmemmap memory.
> > However, depending on the memory is being removed, it might
> > not be always possible to free a full vmemmap page / huge-page
> > because part of it might still be used.
> > 
> > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables
> > hot-remove") introduced a workaround for x86
> > hot-remove, by which partially unused areas are filled with
> > the 0xFD constant. Full pages are only removed when fully
> > filled by 0xFDs.
> > 
> > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with
> > the goal of using it in place of 0xFDs. For now, this will be used for
> > the arm64 port of memory hot remove, but the idea is to eventually use
> > the same mechanism for x86 as well.
> 
> Why cannot you use the same approach as x86 have? Have a look at the
> vmemmap_free at al.
> 

This arm64 hot-remove version (including vmemmap_free) is indeed an
almost 1-to-1 port of the x86 approach. 

If you look at the first version of the patchset we submitted a while 
ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the
x86 approach of filling unsued page structs with 0xFDs. Commenting on
that, Mark suggested (and, indeed, I agree with him) that relying on a
magic constant for marking some portions of physical memory was quite
ugly. That is why we have used memblock for the purpose in this revised
patchset.

If you have a different view and any concrete suggestion on how to
improve this, it is definitely very well welcome. 

> > Signed-off-by: Andrea Reale <ar@linux.vnet.ibm.com>
> > Signed-off-by: Maciej Bielski <m.bielski@virtualopensystems.com>
> > ---
> >  include/linux/memblock.h | 12 ++++++++++++
> >  mm/memblock.c            | 32 ++++++++++++++++++++++++++++++++
> >  2 files changed, 44 insertions(+)
> > 
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index bae11c7..0daec05 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -26,6 +26,9 @@ enum {
> >  	MEMBLOCK_HOTPLUG	= 0x1,	/* hotpluggable region */
> >  	MEMBLOCK_MIRROR		= 0x2,	/* mirrored region */
> >  	MEMBLOCK_NOMAP		= 0x4,	/* don't add to kernel direct mapping */
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +	MEMBLOCK_UNUSED_VMEMMAP	= 0x8,  /* Mark VMEMAP blocks as dirty */
> > +#endif
> >  };
> >  
> >  struct memblock_region {
> > @@ -90,6 +93,10 @@ int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
> >  int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
> >  int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
> >  ulong choose_memblock_flags(void);
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +int memblock_mark_unused_vmemmap(phys_addr_t base, phys_addr_t size);
> > +int memblock_clear_unused_vmemmap(phys_addr_t base, phys_addr_t size);
> > +#endif
> >  
> >  /* Low level functions */
> >  int memblock_add_range(struct memblock_type *type,
> > @@ -182,6 +189,11 @@ static inline bool memblock_is_nomap(struct memblock_region *m)
> >  	return m->flags & MEMBLOCK_NOMAP;
> >  }
> >  
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +bool memblock_is_vmemmap_unused_range(struct memblock_type *mt,
> > +		phys_addr_t start, phys_addr_t end);
> > +#endif
> > +
> >  #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> >  int memblock_search_pfn_nid(unsigned long pfn, unsigned long *start_pfn,
> >  			    unsigned long  *end_pfn);
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 9120578..30d5aa4 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -809,6 +809,18 @@ int __init_memblock memblock_clear_nomap(phys_addr_t base, phys_addr_t size)
> >  	return memblock_setclr_flag(base, size, 0, MEMBLOCK_NOMAP);
> >  }
> >  
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +int __init_memblock memblock_mark_unused_vmemmap(phys_addr_t base,
> > +		phys_addr_t size)
> > +{
> > +	return memblock_setclr_flag(base, size, 1, MEMBLOCK_UNUSED_VMEMMAP);
> > +}
> > +int __init_memblock memblock_clear_unused_vmemmap(phys_addr_t base,
> > +		phys_addr_t size)
> > +{
> > +	return memblock_setclr_flag(base, size, 0, MEMBLOCK_UNUSED_VMEMMAP);
> > +}
> > +#endif
> >  /**
> >   * __next_reserved_mem_region - next function for for_each_reserved_region()
> >   * @idx: pointer to u64 loop variable
> > @@ -1696,6 +1708,26 @@ void __init_memblock memblock_trim_memory(phys_addr_t align)
> >  	}
> >  }
> >  
> > +#ifdef CONFIG_MEMORY_HOTREMOVE
> > +bool __init_memblock memblock_is_vmemmap_unused_range(struct memblock_type *mt,
> > +		phys_addr_t start, phys_addr_t end)
> > +{
> > +	u64 i;
> > +	struct memblock_region *r;
> > +
> > +	i = memblock_search(mt, start);
> > +	r = &(mt->regions[i]);
> > +	while (r->base < end) {
> > +		if (!(r->flags & MEMBLOCK_UNUSED_VMEMMAP))
> > +			return 0;
> > +
> > +		r = &(memblock.memory.regions[++i]);
> > +	}
> > +
> > +	return 1;
> > +}
> > +#endif
> > +
> >  void __init_memblock memblock_set_current_limit(phys_addr_t limit)
> >  {
> >  	memblock.current_limit = limit;
> > -- 
> > 2.7.4
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo at kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>

Thanks,
Andrea

> 
> -- 
> Michal Hocko
> SUSE Labs
> 

  reply	other threads:[~2017-12-04 11:49 UTC|newest]

Thread overview: 156+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-23 11:13 [PATCH v2 0/5] Memory hotplug support for arm64 - complete patchset v2 Andrea Reale
2017-11-23 11:13 ` Andrea Reale
2017-11-23 11:13 ` Andrea Reale
2017-11-23 11:13 ` [PATCH v2 1/5] mm: memory_hotplug: Memory hotplug (add) support for arm64 Maciej Bielski
2017-11-23 11:13   ` Maciej Bielski
2017-11-23 11:13   ` Maciej Bielski
2017-11-24  5:55   ` Arun KS
2017-11-24  5:55     ` Arun KS
2017-11-24  5:55     ` Arun KS
2017-11-24  9:42     ` Andrea Reale
2017-11-24  9:42       ` Andrea Reale
2017-11-24  9:42       ` Andrea Reale
2017-11-24 10:53       ` Maciej Bielski
2017-11-24 10:53         ` Maciej Bielski
2017-11-24 10:53         ` Maciej Bielski
2017-11-26  6:58         ` Arun KS
2017-11-26  6:58           ` Arun KS
2017-11-26  6:58           ` Arun KS
2017-11-27 15:19   ` Robin Murphy
2017-11-27 15:19     ` Robin Murphy
2017-11-27 15:19     ` Robin Murphy
2017-11-27 16:39     ` Maciej Bielski
2017-11-27 16:39       ` Maciej Bielski
2017-11-27 16:39       ` Maciej Bielski
2017-11-27 17:11       ` Andrea Reale
2017-11-27 17:11         ` Andrea Reale
2017-11-27 17:11         ` Andrea Reale
2017-11-23 11:14 ` [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove Andrea Reale
2017-11-23 11:14   ` Andrea Reale
2017-11-23 11:14   ` Andrea Reale
2017-11-23 22:18   ` Rafael J. Wysocki
2017-11-23 22:18     ` Rafael J. Wysocki
2017-11-23 22:18     ` Rafael J. Wysocki
2017-11-24 14:39   ` Rafael J. Wysocki
2017-11-24 14:39     ` Rafael J. Wysocki
2017-11-24 14:39     ` Rafael J. Wysocki
2017-11-24 14:49     ` Andrea Reale
2017-11-24 14:49       ` Andrea Reale
2017-11-24 14:49       ` Andrea Reale
2017-11-24 14:49       ` Andrea Reale
2017-11-24 15:43       ` Michal Hocko
2017-11-24 15:43         ` Michal Hocko
2017-11-24 15:43         ` Michal Hocko
2017-11-24 15:43         ` Michal Hocko
2017-11-24 15:54         ` Andrea Reale
2017-11-24 15:54           ` Andrea Reale
2017-11-24 15:54           ` Andrea Reale
2017-11-24 15:54           ` Andrea Reale
2017-11-24 18:17           ` Michal Hocko
2017-11-24 18:17             ` Michal Hocko
2017-11-24 18:17             ` Michal Hocko
2017-11-24 18:17             ` Michal Hocko
2017-11-29  1:20             ` joeyli
2017-11-29  1:20               ` joeyli
2017-11-29  1:20               ` joeyli
2017-11-29  1:20               ` joeyli
2017-11-30  9:47               ` Michal Hocko
2017-11-30  9:47                 ` Michal Hocko
2017-11-30  9:47                 ` Michal Hocko
2017-11-30  9:47                 ` Michal Hocko
2017-11-27 15:20           ` Robin Murphy
2017-11-27 15:20             ` Robin Murphy
2017-11-27 15:20             ` Robin Murphy
2017-11-27 15:20             ` Robin Murphy
2017-11-27 17:44             ` Andrea Reale
2017-11-27 17:44               ` Andrea Reale
2017-11-27 17:44               ` Andrea Reale
2017-11-27 17:44               ` Andrea Reale
2017-11-29  0:49   ` joeyli
2017-11-29  0:49     ` joeyli
2017-11-29  0:49     ` joeyli
2017-11-29  1:52     ` joeyli
2017-11-29  1:52       ` joeyli
2017-11-29  1:52       ` joeyli
2017-12-04 11:28       ` Andrea Reale
2017-12-04 11:28         ` Andrea Reale
2017-12-04 11:28         ` Andrea Reale
2017-12-04 14:05         ` Rafael J. Wysocki
2017-12-04 14:05           ` Rafael J. Wysocki
2017-12-04 14:05           ` Rafael J. Wysocki
2017-11-23 11:14 ` [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem Andrea Reale
2017-11-23 11:14   ` Andrea Reale
2017-11-23 11:14   ` Andrea Reale
2017-11-27 15:20   ` Robin Murphy
2017-11-27 15:20     ` Robin Murphy
2017-11-27 15:20     ` Robin Murphy
2017-11-27 17:38     ` Andrea Reale
2017-11-27 17:38       ` Andrea Reale
2017-11-27 17:38       ` Andrea Reale
2017-11-30 14:51   ` Michal Hocko
2017-11-30 14:51     ` Michal Hocko
2017-11-30 14:51     ` Michal Hocko
2017-12-04 11:49     ` Andrea Reale [this message]
2017-12-04 11:49       ` Andrea Reale
2017-12-04 11:49       ` Andrea Reale
2017-12-04 12:32       ` Michal Hocko
2017-12-04 12:32         ` Michal Hocko
2017-12-04 12:32         ` Michal Hocko
2017-12-04 12:42         ` Andrea Reale
2017-12-04 12:42           ` Andrea Reale
2017-12-04 12:42           ` Andrea Reale
2017-12-04 12:48           ` Michal Hocko
2017-12-04 12:48             ` Michal Hocko
2017-12-04 12:48             ` Michal Hocko
2017-11-23 11:14 ` [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe device Andrea Reale
2017-11-23 11:14   ` Andrea Reale
2017-11-23 11:14   ` Andrea Reale
2017-11-24 10:35   ` zhong jiang
2017-11-24 10:35     ` zhong jiang
2017-11-24 10:35     ` zhong jiang
2017-11-24 10:44     ` Andrea Reale
2017-11-24 10:44       ` Andrea Reale
2017-11-24 10:44       ` Andrea Reale
2017-11-24 12:17       ` zhong jiang
2017-11-24 12:17         ` zhong jiang
2017-11-24 12:17         ` zhong jiang
2017-11-24 14:29         ` Andrea Reale
2017-11-24 14:29           ` Andrea Reale
2017-11-24 14:29           ` Andrea Reale
2017-12-04 17:50           ` Reza Arbab
2017-12-04 17:50             ` Reza Arbab
2017-12-04 17:50             ` Reza Arbab
2017-11-27 15:33   ` Robin Murphy
2017-11-27 15:33     ` Robin Murphy
2017-11-27 15:33     ` Robin Murphy
2017-11-27 17:14     ` Andrea Reale
2017-11-27 17:14       ` Andrea Reale
2017-11-27 17:14       ` Andrea Reale
2017-11-30 14:49   ` Michal Hocko
2017-11-30 14:49     ` Michal Hocko
2017-11-30 14:49     ` Michal Hocko
2017-12-04 11:51     ` Andrea Reale
2017-12-04 11:51       ` Andrea Reale
2017-12-04 11:51       ` Andrea Reale
2017-12-04 12:33       ` Michal Hocko
2017-12-04 12:33         ` Michal Hocko
2017-12-04 12:33         ` Michal Hocko
2017-12-04 12:44         ` Andrea Reale
2017-12-04 12:44           ` Andrea Reale
2017-12-04 12:44           ` Andrea Reale
2017-11-23 11:15 ` [PATCH v2 5/5] mm: memory-hotplug: Add memory hot remove support for arm64 Andrea Reale
2017-11-23 11:15   ` Andrea Reale
2017-11-23 11:15   ` Andrea Reale
2017-11-23 16:02 ` [PATCH v2 0/5] Memory hotplug support for arm64 - complete patchset v2 Michal Hocko
2017-11-23 16:02   ` Michal Hocko
2017-11-23 16:02   ` Michal Hocko
2017-11-23 17:33   ` Andrea Reale
2017-11-23 17:33     ` Andrea Reale
2017-11-23 17:33     ` Andrea Reale
2017-11-30 14:57     ` Michal Hocko
2017-11-30 14:57       ` Michal Hocko
2017-11-30 14:57       ` Michal Hocko
2017-12-04 11:34       ` Andrea Reale
2017-12-04 11:34         ` Andrea Reale
2017-12-04 11:34         ` Andrea Reale
2017-11-24 10:22 ` [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove Andrea Reale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171204114908.GC6373@samekh \
    --to=ar@linux.vnet.ibm.com \
    --cc=arunks@qti.qualcomm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.bielski@virtualopensystems.com \
    --cc=mark.rutland@arm.com \
    --cc=mhocko@kernel.org \
    --cc=qiuxishi@huawei.com \
    --cc=realean2@ie.ibm.com \
    --cc=scott.branden@broadcom.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.