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

[bhe at redhat.com]

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.

Thanks
Baoquan

> 
>