On 10/28/13 at 11:12am, Vivek Goyal wrote: > On Thu, Oct 24, 2013 at 10:48:29PM -0700, Yinghai Lu wrote: > > On Thu, Oct 24, 2013 at 12:27 PM, Vivek Goyal <vgoyal at redhat.com> wrote: > > > On Thu, Oct 24, 2013 at 12:24:57PM -0700, Yinghai Lu wrote: > > >> On Thu, Oct 24, 2013 at 12:18 PM, Vivek Goyal <vgoyal at redhat.com> wrote: > > >> > On Thu, Oct 24, 2013 at 12:15:25PM -0700, Yinghai Lu wrote: > > >> > > > >> > Also keeping things simple by not trying to *impose* a new crashkernel= > > >> > syntax on existing crashkernel=xM users. > > >> > > >> Existing user that have crashkernel=xM working with their old kernel > > >> and old kexec-tools, they still could keep their old command line and > > >> old kexec-tools > > >> with new updated kernel. > > >> We should not change semantics to surprise them. > > > > > > Old users will get reservation still below 896MB. > > > > > > It will go above 896MB only if memory could not be allocated below 896MB. > > > > > > In the past reservation will fail and kexec-tools will fail. > > > Now reservation will succeed but kexec-tools will fail. > > > > > > So end result a user sees is that kexec-tools fails. So I don't see how > > > we are breaking existing installations or user setups. > > > > case could be: if user add more memory and put more pcie cards, and > > second kernel will need more ram and OOM there. > > Now makedumpfile supports cyclic mode by default. So one does not have > to necessarily linearly scale reserved memory based on physical memory > present in the box. > > > so user could just increase crashkernel=512M to crashkernel=1G. > > If user has new makedumpfile, OOM should not happen and one should not > have to increase memory reservation. > > > > > without Cong's patch, kernel will fail to reserve, and user would dig > > to change it > > to crashkernel=1G,high, and update kexec-tools. > > > > with Cong's patch, kernel will reserve other range like between 896 > > and 4G, old kexec-tools either > > fail to load second kernel or hang in purgatory or early stage of > > second kernel, or other unknown behavior. > > I understand your concern about memory being reserved high and kexec > just hanging. Only thing I am arguing is that the number of cases where > it will happen is small. > > - First of all for all old existing kexec-tools memory will stil come > from 896MB. > - Old kexec-tools enforced that purgatory is loaded below 2G. So if > memory is reserved above 2G, kexec-tools will fail. > > So only problematic case seems to be that if user increased crashkernel=X > value and memory got reserved between 896M and 2G. But this is not same > as breaking old setups as old setups anyway never worked with this > configuration. > > You argument that user will research and upgrade kexec-tools and use > crashkernel=X,high, then it holds true for the case where memory is > reserved between 896M and 2G. > > I personally think that it is easier for a user to not change any > kernel parameters with kernel and kexec-tools upgrade and still be > able to work with large memory systems. So the benefit of extending > the semantics of existing parameter seems to be outweighing the downside > of side, IMHO. > > > > > I would think first path is much clear and predicted. > > > > If my memory is right, HPA did not like idea that we try below 896M, > > and then under 4G and then above 4G. > > hpa, I know you did not like the idea in the past. Is it still the case. Hi, hpa Do you still not like this idea? Could you make it more clear to us please? Thanks Chao > > IMHO, I like the fact that existing users still be able to work with > crashkernel=X and not forced to switch to crashkernel=x,high and also incur > the penalty of reserving extra memory for software iotlb. > > Thanks > Vivek
