From: Lisa Mitchell <lisa.mitchell@hp.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Vivek Goyal <vgoyal@redhat.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH 0/3] makedumpfile: calculate the size of cyclic buffer automatically.
Date: Fri, 09 Nov 2012 03:46:21 -0700 [thread overview]
Message-ID: <1352457981.13097.122.camel@lisamlinux.fc.hp.com> (raw)
In-Reply-To: <20121109141717.GB4842@redhat.com>
On Fri, 2012-11-09 at 14:17 +0000, Vivek Goyal wrote:
> On Fri, Nov 09, 2012 at 04:02:14PM +0900, Atsushi Kumagai wrote:
> > Hello,
> >
> > I made the patch set based on v1.5.1-beta to calculate the size of cyclic
> > buffer automatically.
> >
> > In v1.5.0, users have to specify the buffer size depending on system memory
> > size with --cyclic-buffer option in order to get decent performance.
> >
> > This patch set avoids the inconvenience above by choosing the lesser value
> > of the two below as the size of cyclic buffer automatically:
> >
> > a. the size enough for storing the 1st/2nd bitmap for the whole of vmcore
> > b. 80% of free memory (as safety limit)
> >
> > Additionally, this patch set remove --cyclic-buffer option because I think
> > it has been already unnecessary.
>
> I was wondering how about retaining --cyclic-buffer <size> option. If
> there are use cases where user's don't like default of 80% of free memory
> they can override this policy by specifying --cyclic-buffer.
>
> Thanks
> Vivek
I second that, I'd like the --cyclic-buffer option to stay. I see PATCH
3/3 to remove cyclic buffer option, and I also would like it left there,
for debug of issues that may come up later. It's great that the code
will automatically calculate the best cyclic buffer option, which is
what it should do for the best customer out-of-the-box dump enablement,
but the ability to manipulate it for debug purposes, or for workarounds
if things go wrong, is valuable.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-11-09 14:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-09 7:02 [PATCH 0/3] makedumpfile: calculate the size of cyclic buffer automatically Atsushi Kumagai
2012-11-09 7:02 ` [PATCH 1/3] Add get_free_memory_size() to get the amount of free memory Atsushi Kumagai
2012-11-09 7:04 ` [PATCH 2/3] Calculate the size of cyclic buffer automatically Atsushi Kumagai
2012-11-09 7:04 ` [PATCH 3/3] Remove --cyclic-buffer option Atsushi Kumagai
2012-11-09 14:17 ` [PATCH 0/3] makedumpfile: calculate the size of cyclic buffer automatically Vivek Goyal
2012-11-09 10:46 ` Lisa Mitchell [this message]
2012-11-12 7:23 ` Atsushi Kumagai
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=1352457981.13097.122.camel@lisamlinux.fc.hp.com \
--to=lisa.mitchell@hp.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
--cc=vgoyal@redhat.com \
/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.