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.
