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

[bhe at redhat.com]

On 04/24/14 at 07:50am, Baoquan He wrote:
> On 04/23/14 at 01:08pm, Vivek Goyal wrote:
>  
> > >  - bitmap size: used for 1st and 2nd bitmaps
> > >  - remains: can be used for the other works of makedumpfile (e.g. I/O buffer)
> > > 
> > >                  pattern                      |  bitmap size  |   remains
> > > ----------------------------------------------+---------------+-------------
> > >   A. 100G memory with the too allocation bug  |    12.8 MB    |   17.2 MB
> > >   B. 100G memory with fixed makedumpfile      |     6.4 MB    |   23.6 MB
> > >   C. 200G memory with fixed makedumpfile      |    12.8 MB    |   17.2 MB
> > >   D. 300G memory with fixed makedumpfile      |    19.2 MB    |   10.8 MB
> > >   E. 400G memory with fixed makedumpfile      |    24.0 MB    |    6.0 MB
> > >   F. 500G memory with fixed makedumpfile      |    24.0 MB    |    6.0 MB
> > >   ...
> > > 
> > > Baoquan got OOM in A pattern and didn't get it in B, so C must also
> > > fail due to OOM. This is just what I wanted to say.
> > 
> > ok, So here bitmap size is growing because we have not hit the 80% of 
> > available memory limit yet. But it gets limited at 24MB once we hit
> > 80% limit. I think that's fine. That's what I was looking for.
> > 
> > Now key question will remain is that is using 80% of free memory by
> > bitmaps too much. Are other things happening in system which consume
> > memory and because memory is not available OOM hits. If that's the
> > case we probably need to lower the amount of memory allocated to
> > bit maps. Say 70% or 60% or may be 50%. But this should be data driven.
> 
> How about add anoter limit, say left memory safety limit, e.g 20M. If
> the remaining memory which is 20% of free memory is bigger than 20M, 80%
> can be taken to calculate the bitmap size. If smaller than 20M, we just
> take (total memory - safety limit) for bitmap size.

Oh, this is what Astushi suggested earlier in his comments.