Re: [PATCH] fadump: Register the memory reserved by fadump

* Michael Ellerman [2016-08-10 16:57:57]: > Srikar Dronamraju writes: > > >> > >> > Conceptually it would be cleaner, if expensive, to calculate the real > >> > memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve > >> > and

Re: [PATCH] fadump: Register the memory reserved by fadump

On Wed, Aug 10, 2016 at 04:02:47PM +1000, Michael Ellerman wrote: > > Conceptually it would be cleaner, if expensive, to calculate the real > > memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve > > and nr_kernel_pages entirely. > > Why is it expensive? memblock tracks the

Re: [PATCH] fadump: Register the memory reserved by fadump

Srikar Dronamraju writes: >> >> > Conceptually it would be cleaner, if expensive, to calculate the real >> > memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve >> > and nr_kernel_pages entirely. >> >> Why is it expensive? memblock tracks the

Re: [PATCH] fadump: Register the memory reserved by fadump

> > > Conceptually it would be cleaner, if expensive, to calculate the real > > memblock reserves if HASH_EARLY and ditch the dma_reserve, memory_reserve > > and nr_kernel_pages entirely. > > Why is it expensive? memblock tracks the totals for all memory and > reserved memory AFAIK, so it should

Re: [PATCH] fadump: Register the memory reserved by fadump

Mel Gorman writes: > On Fri, Aug 05, 2016 at 07:25:03PM +1000, Michael Ellerman wrote: >> > One way to do that would be to walk through the different memory >> > reserved blocks and calculate the size. But Mel feels thats an >> > overhead (from his reply to the other

Re: [PATCH] fadump: Register the memory reserved by fadump

On Fri, Aug 05, 2016 at 07:25:03PM +1000, Michael Ellerman wrote: > > One way to do that would be to walk through the different memory > > reserved blocks and calculate the size. But Mel feels thats an > > overhead (from his reply to the other thread) esp for just one use > > case. > > OK. I

Re: [PATCH] fadump: Register the memory reserved by fadump

Srikar Dronamraju writes: > * Michael Ellerman [2016-08-05 17:07:01]: > >> Srikar Dronamraju writes: >> >> > Fadump kernel reserves large chunks of memory even before the pages are >> > initialized. This could mean

Re: [PATCH] fadump: Register the memory reserved by fadump

* Michael Ellerman [2016-08-05 17:07:01]: > Srikar Dronamraju writes: > > > Fadump kernel reserves large chunks of memory even before the pages are > > initialized. This could mean memory that corresponds to several nodes might > > fall in

Re: [PATCH] fadump: Register the memory reserved by fadump

Srikar Dronamraju writes: > Fadump kernel reserves large chunks of memory even before the pages are > initialized. This could mean memory that corresponds to several nodes might > fall in memblock reserved regions. > ... > Register the memory reserved by fadump, so

Re: [PATCH] fadump: Register the memory reserved by fadump

* Mel Gorman [2016-08-04 15:09:34]: > > > > Suggested-by: Mel Gorman > > I didn't suggest this specifically. While it happens to be safe on ppc64, > it potentially overwrites any future caller of set_dma_reserve. While the > only other

Re: [PATCH] fadump: Register the memory reserved by fadump

On Thu, Aug 04, 2016 at 07:12:45PM +0530, Srikar Dronamraju wrote: > Fadump kernel reserves large chunks of memory even before the pages are > initialized. This could mean memory that corresponds to several nodes might > fall in memblock reserved regions. > > Kernels compiled with

[PATCH] fadump: Register the memory reserved by fadump

Fadump kernel reserves large chunks of memory even before the pages are initialized. This could mean memory that corresponds to several nodes might fall in memblock reserved regions. Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialize only certain size memory per node. The