All of lore.kernel.org
 help / color / mirror / Atom feed
From: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
To: "bhe@redhat.com" <bhe@redhat.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: RE: [PATCH 3/3] Stop maximizing the bitmap buffer to reduce the risk of OOM.
Date: Tue, 17 Jun 2014 02:32:26 +0000	[thread overview]
Message-ID: <0910DD04CBD6DE4193FCF86B9C00BE97223015@BPXM01GP.gisp.nec.co.jp> (raw)
In-Reply-To: <20140616082959.GA1718@dhcp-16-105.nay.redhat.com>

Hello Baoquan,

Thanks for your careful review.

>On 06/10/14 at 04:54am, Atsushi Kumagai wrote:
>> We tried to maximize the bitmap buffer to get the best performance,
>> but the performance degradation caused by multi-cycle processing
>> looks very small according to the benchmark on 2TB memory:
>>
>>   https://lkml.org/lkml/2013/3/26/914
>>
>> This result means we don't need to make an effort to maximize the
>> bitmap buffer, it will just increase the risk of OOM.
>>
>> This patch sets a small fixed value (4MB) as a safety limit,
>> it may be safer and enough in most cases.
>>
>> Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
>> ---
>>  makedumpfile.c | 17 ++++++++++-------
>>  1 file changed, 10 insertions(+), 7 deletions(-)
>>
>> diff --git a/makedumpfile.c b/makedumpfile.c
>> index b8f1ec4..c23667b 100644
>> --- a/makedumpfile.c
>> +++ b/makedumpfile.c
>> @@ -8946,13 +8946,15 @@ out:
>>
>>
>>  /*
>> - * Choose the lesser value of the two below as the size of cyclic buffer.
>> - *  - the size enough for storing the 1st/2nd bitmap for the whole of vmcore
>> - *  - 80% of free memory (as safety limit)
>> + * Choose the lesser value of the three below as the size of cyclic buffer.
>                 ~~~~~ typo, it should be less.

I'll fix it.

>> + *  - the size enough for storing the 1st or 2nd bitmap for the whole of vmcore
>> + *  - 4MB as sufficient value
>> + *  - 60% of free memory as safety limit
>>   */
>>  int
>>  calculate_cyclic_buffer_size(void) {
>>  	unsigned long long limit_size, bitmap_size;
>> +	const unsigned long long maximum_size = 4 * 1024 * 1024;
>>
>>  	if (info->max_mapnr <= 0) {
>>  		ERRMSG("Invalid max_mapnr(%llu).\n", info->max_mapnr);
>> @@ -8960,17 +8962,18 @@ calculate_cyclic_buffer_size(void) {
>>  	}
>>
>>  	/*
>> -	 *  We should keep the size of cyclic buffer within 80% of free memory
>> -	 *  for safety.
>> +	 *  At least, we should keep the size of cyclic buffer within 60% of
>> +	 *  free memory for safety.
>>  	 */
>> -	limit_size = get_free_memory_size() * 0.8;
>> +	limit_size = get_free_memory_size() * 0.6;
>>  	bitmap_size = info->max_mapnr / BITPERBYTE;
>>
>>  	/* if --split was specified cyclic buffer allocated per dump file */
>>  	if (info->num_dumpfile > 1)
>>  		bitmap_size /= info->num_dumpfile;
>>
>> -	info->bufsize_cyclic = MIN(limit_size, bitmap_size);
>> +	/* 4MB will be enought for performance according to benchmarks. */
>                      ~~~~~~~~
>There's a typo, here should be enough.

I'll fix it.


Thanks
Atsushi Kumagai

>> +	info->bufsize_cyclic = MIN(MIN(limit_size, maximum_size), bitmap_size);
>>
>>  	return TRUE;
>>  }
>> --
>> 1.9.0
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec

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

      reply	other threads:[~2014-06-17  2:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-10  4:54 [PATCH 3/3] Stop maximizing the bitmap buffer to reduce the risk of OOM Atsushi Kumagai
2014-06-16  8:29 ` Baoquan He
2014-06-17  2:32   ` Atsushi Kumagai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0910DD04CBD6DE4193FCF86B9C00BE97223015@BPXM01GP.gisp.nec.co.jp \
    --to=kumagai-atsushi@mxc.nes.nec.co.jp \
    --cc=bhe@redhat.com \
    --cc=kexec@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.