Re: [PATCH 2/2] fadump: Disable deferred page struct initialisation

[Mel Gorman <mgorman@techsingularity.net>]

On Thu, Aug 04, 2016 at 10:40:35AM +0530, Srikar Dronamraju wrote:
> * Dave Hansen <dave.hansen@intel.com> [2016-08-03 12:40:17]:
> 
> > On 08/02/2016 11:35 PM, Srikar Dronamraju wrote:
> > > On a regular kernel with CONFIG_FADUMP and fadump configured, 5% of the
> > > total memory is reserved for booting the kernel on crash.  On crash,
> > > fadump kernel reserves the 95% memory and boots into the 5% memory that
> > > was reserved for it. It then parses the reserved 95% memory to collect
> > > the dump.
> > > 
> > > The problem is not about the amount of memory thats reserved for fadump
> > > kernel. Even if we increase/decrease, we will still end up with the same
> > > issue.
> > 
> > Oh, and the dentry/inode caches are sized based on 100% of memory, not
> > the 5% that's left after the fadump reservation?
> 
> Yes, the dentry/inode caches are sized based on the 100% memory.
> 

By and large, I'm not a major fan of introducing an API to disable it for
a single feature that is arch-specific because it's very heavy handed.
There is no guarantee that the existence of fadump will cause a failure

If fadump is reserving memory and alloc_large_system_hash(HASH_EARLY)
does not know about then then would an arch-specific callback for
arch_reserved_kernel_pages() be more appropriate? fadump would need to
return how many pages it reserved there. That would shrink the size of
the inode and dentry hash tables when booting with 95% of memory
reserved.

That approach would limit the impact to ppc64 and would be less costly than
doing a memblock walk instead of using nr_kernel_pages for everyone else.

> > Is the deferred initialization kicked in progress at the time we do the
> > dentry/inode allocations?  Can waiting a bit let the allocation succeed?
> > 
> 
> Right now deferred initialisation kicks in after dentry/inode
> allocations.
> 
> Can we defer the cache allocations till deferred
> initialisation? I dont know.

Only by backing it with vmalloc memory.

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