Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed 26-07-17 10:33:31, Michal Hocko wrote: [...] > @@ -312,7 +324,7 @@ int __ref __add_pages(int nid, unsigned long > phys_start_pfn, > } > > for (i = start_sec; i <= end_sec; i++) { > - err = __add_section(nid, section_nr_to_pfn(i), want_memblock); > +

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed 26-07-17 10:33:31, Michal Hocko wrote: [...] > @@ -312,7 +324,7 @@ int __ref __add_pages(int nid, unsigned long > phys_start_pfn, > } > > for (i = start_sec; i <= end_sec; i++) { > - err = __add_section(nid, section_nr_to_pfn(i), want_memblock); > +

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed 26-07-17 19:20:39, Gerald Schaefer wrote: > On Wed, 26 Jul 2017 14:30:41 +0200 > Michal Hocko wrote: > > > On Wed 26-07-17 13:45:39, Heiko Carstens wrote: > > [...] > > > In general I do like your idea, however if I understand your patches > > > correctly we might have

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed 26-07-17 19:20:39, Gerald Schaefer wrote: > On Wed, 26 Jul 2017 14:30:41 +0200 > Michal Hocko wrote: > > > On Wed 26-07-17 13:45:39, Heiko Carstens wrote: > > [...] > > > In general I do like your idea, however if I understand your patches > > > correctly we might have an ordering problem

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, 26 Jul 2017 14:30:41 +0200 Michal Hocko wrote: > On Wed 26-07-17 13:45:39, Heiko Carstens wrote: > [...] > > In general I do like your idea, however if I understand your patches > > correctly we might have an ordering problem on s390: it is not possible to > > access

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, 26 Jul 2017 14:30:41 +0200 Michal Hocko wrote: > On Wed 26-07-17 13:45:39, Heiko Carstens wrote: > [...] > > In general I do like your idea, however if I understand your patches > > correctly we might have an ordering problem on s390: it is not possible to > > access hot-added memory on

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed 26-07-17 13:45:39, Heiko Carstens wrote: [...] > In general I do like your idea, however if I understand your patches > correctly we might have an ordering problem on s390: it is not possible to > access hot-added memory on s390 before it is online (MEM_GOING_ONLINE > succeeded). Could you

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed 26-07-17 13:45:39, Heiko Carstens wrote: [...] > In general I do like your idea, however if I understand your patches > correctly we might have an ordering problem on s390: it is not possible to > access hot-added memory on s390 before it is online (MEM_GOING_ONLINE > succeeded). Could you

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, Jul 26, 2017 at 01:45:39PM +0200, Heiko Carstens wrote: > > Please note that only the memory hotplug is currently using this > > allocation scheme. The boot time memmap allocation could use the same > > trick as well but this is not done yet. > > Which kernel are these patches based on? I

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, Jul 26, 2017 at 01:45:39PM +0200, Heiko Carstens wrote: > > Please note that only the memory hotplug is currently using this > > allocation scheme. The boot time memmap allocation could use the same > > trick as well but this is not done yet. > > Which kernel are these patches based on? I

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, Jul 26, 2017 at 10:33:31AM +0200, Michal Hocko wrote: > From: Michal Hocko > > Physical memory hotadd has to allocate a memmap (struct page array) for > the newly added memory section. kmalloc is currantly used for those > allocations. > > This has some disadvantages a)

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, Jul 26, 2017 at 10:33:31AM +0200, Michal Hocko wrote: > From: Michal Hocko > > Physical memory hotadd has to allocate a memmap (struct page array) for > the newly added memory section. kmalloc is currantly used for those > allocations. > > This has some disadvantages a) an existing

[RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

From: Michal Hocko Physical memory hotadd has to allocate a memmap (struct page array) for the newly added memory section. kmalloc is currantly used for those allocations. This has some disadvantages a) an existing memory is consumed for that purpose (~2MB per 128MB memory

[RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

From: Michal Hocko Physical memory hotadd has to allocate a memmap (struct page array) for the newly added memory section. kmalloc is currantly used for those allocations. This has some disadvantages a) an existing memory is consumed for that purpose (~2MB per 128MB memory section) and b) if