Re: [PATCH] makedumpfile: change the wrong code to calculate bufsize_cyclic for elf dump

From: "bhe@redhat.com" <bhe@redhat.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "d.hatayama@jp.fujitsu.com" <d.hatayama@jp.fujitsu.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"zzou@redhat.com" <zzou@redhat.com>,
	"vgoyal@redhat.com" <vgoyal@redhat.com>
Subject: Re: [PATCH] makedumpfile: change the wrong code to calculate bufsize_cyclic for elf dump
Date: Fri, 18 Apr 2014 22:29:12 +0800	[thread overview]
Message-ID: <20140418142912.GA2023@dhcp-17-102.nay.redhat.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9720542E@BPXM01GP.gisp.nec.co.jp>

> >> It definitely will cause OOM. On my test machine, it has 100G memory. So
> >> per old code, its needed_size is 3200K*2 == 6.4M, if currently free
> >> memory is only 15M left, the free_size will be 15M*0.4 which is 6M. So
> >> info->bufsize_cyclic is assigned to be 6M. and only 3M is left for other
> >> use, e.g page cache, dynamic allocation. OOM will happen.
> >>
> >
> >BTW, in our case, there's about 30M free memory when we started saving
> >dump. It should be caused by my coarse estimation above.
> 
> Thanks for your description, I understand that situation and
> the nature of the problem.
> 
> That is, the assumption that 20% of free memory is enough for
> makedumpfile can be broken if free memory is too small.
> If your machine has 200GB memory, OOM will happen even after fix
> the too allocation bug.

Well, we have done some experiments to try to get the statistical memory
range which kdump really need. Then a final reservation will be
calculated automatically as (base_value + linear growth of total memory). 
If one machine has 200GB memory, its reservation will grow too. Since
except of the bitmap cost, other memory cost is almost fixed. 

Per this scheme things should be go well, if memory always goes to the
edge of OOM, an adjust of base_value is needed. So a constant value as
you said may not be needed.

Instead, I am wondering how the 80% comes from, and why 20% of free
memory must be safe.
> 
> I don't think this is a problem, it's natural that a lack of memory
> causes OOM. However, there is a thing we can do for improvement. 
> 
> What I think is:
> 
>   1. Use a constant value as safe limit to calculate bufsize_cyclic
>      instead of 80% of free memory. This value must be enough for
>      makedumpfile's work except bitmap.
> 
>   2. If free memory is smaller than the value, makedumpfile gives up
>      to work early.
> 
> This change may reduce the possibility of lack of memory, but the
> required memory size will be changing every version, so maintaining
> it sounds tough to me.
> 
> Any comments are welcome.
> 
> 
> Thanks
> Atsushi Kumagai

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec