On Tue, Apr 2, 2013 at 1:11 PM, Vivek Goyal <vgo...@redhat.com> wrote: > On Tue, Apr 02, 2013 at 01:00:46PM -0700, Yinghai Lu wrote: >> On Tue, Apr 2, 2013 at 12:11 PM, Vivek Goyal <vgo...@redhat.com> wrote: >> > On Tue, Apr 02, 2013 at 11:49:13AM -0700, Yinghai Lu wrote: >> >> On Tue, Apr 2, 2013 at 11:42 AM, Yinghai Lu <ying...@kernel.org> wrote: >> >> > aka: >> >> > old kexec-tools stay with "crashkernel=X" >> >> > new kexec-tools stay with >> >> > 1. like old kexec tools >> >> > 2. or "crashkernel=X,high" or "crashkernel=X,high crashkernel=Y,low", >> >> > Y could be 100M or 0 etc. >> >> >> >> I keep the old logic like: >> >> if there are several "crashkernel=X,high", only last one is honored. >> >> if there are several "crashkernel=Y,low", only last one is honored. >> > >> > Yes but if different types of crashkernel= options are mixes then >> > behavior is not defined. >> >> dmesg or /proc/iomem will show them what is finally reserved. >> >> > >> > crashkernel=X,high crashkernel=X >> >> ==> crashkernel=X is tossed away. > > You are just describing what your code does. There is no theme or > justification behind this behavior. There is no uniformity. A user can > question that so far you used to honor last crashkernel= parameter and > suddenly in 3.9 that's no more the case. Out of blue crashkernel=X,high is > overriding crashkernel=X and it is not obivious why.
Let me repeat again: we keep crashkernel=X old behavior with old kexec-tools. crashkernel=X;high is for new kexec-tools that support loading high. If the user want to use ,high but still with old kexec-tools, that is not going to work. Can we just keep it separated? > >> >> > crashkernel=X,high crashkernel=Y;low >> >> normal case. if user want more or disable low range. > > Again, behavior is not clear to user. Please stop describing your code > behavior. Discuss more in terms of presenting a consistent interface to > user. > >> >> > crashkernel=Y;low crashkernel=X >> >> crashkernel=X will be used. > > Why? When crashkernel=X is specified with crashkernel=Y;high, high takes > over but when crashkernel=X is specified with crashkernel=Y;low, > crashkernel=X takes over. These is highly unintutive. > >> >> > >> > And possibilities go on. So I think it makes life simpler if we always >> > parse last crashkernel= option and act upon that. And use >> > crashkernel_no_auto_low to opt out of auto reserved low memory area. >> >> No, that is not just disable. User could want more like 128M instead of 72M. > > If user wants 128M in low memory, they will just specify > crashkernel=128M;low in the kernel-parameter.txt, already says ;low is need to used with ;high. > > If they want to control multiple ranges of memory, then that's the feature > we currently don't support. Currently we support only reserving one range > of memory. > > If you want to support multiple ranges of memory,then do it properly. > Parse all crashkernel= options, prepare a list of memory to be reserved > and unreserved, resolve all the conflicts between various options and > then reserve the memory. But that does not seem to be a requirement at > this point of time. No we does not support multiple ranges, as it will need more changes in kexec-tools. Can we stop here with those four patches? Later, we can extend it if it is really needed. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/