On 04/17/14 at 12:52pm, Baoquan He wrote: > On 04/17/14 at 04:01am, Atsushi Kumagai wrote: > > Hello Baoquan, > > > > >Hi Atsushi, > > > > > >I have got the test machine where bug reported and did a test. The > > >changed code can make elf dump successful. > > > > Great, thanks for your help! > > However, I still have questions. > > > > First, what is the difference between yours and mine? > > > > http://lists.infradead.org/pipermail/kexec/2014-April/011535.html > > Yeah, you are right, it's the same on changing the code bug. I mush > haven't read your patch carefully. must<-- > > > > > My patch includes renaming some values, but the purpose looks > > the same as yours. > > Further, you described as below, > > > > >On 04/14/14 at 04:02pm, Baoquan He wrote: > > but I still don't think this bug causes OOM. > > Even if needed_size is calculated as so much size wrongly, bufsize_cyclic > > will not exceed 40% of free memory by the check below: > > > > info->bufsize_cyclic = (free_size <= needed_size) ? free_size : needed_size; > > > > So it looks that bitmap1(40%) and bitmap2(40%) will fit in 80% of free > > memory in any case. > > > > I may misunderstand something since your patch has an effect on this > > issue in practice, could you correct me? > > 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.
