Bug 608683

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Created attachment 427496 [details]
patch to dynamically adjust firstboot memory reservation based on usage in kernel

vivek, can you give this patch a try?  It works for me, but I'd like your input to see if its missing anything you think it might need

Ok, fair enough, if we want to scale our memory reservation based on some metric(s) of the running kernel, we need to have valid metrics to base it off, and "amount of slab in use" doesn't sound like it currently fits the bill.  Let me know if you & balbir come up with an alternate metric to use.  Thanks!

*** Bug 656047 has been marked as a duplicate of this bug. ***

We had done some experiments and did not find a strong correlation between memory used by first kernel and second kernel. So I think this is no longer a good approach.

We need to rather come up with some kind of script to roughly predict the memory usage of the kernel. We have done some analysis to figure out where memory is being consumed and we are in fairly good shape to do some rough predictions. The only variable part is that we still don't have any way to predict memory used by loaded modules. So hopefully that will be in the noise with nr_cpus=1. Say use an adhoc factor of 10-20 MB for moudules. In fact use adhoc of 128MB default, and scale it with amount of memory present in system to account for makedumpfile. 2bits per page and that should be good enough on many systems.

As we have not found a any strong correlation between first kernel's and second kernel's memory usage, this is not a good approach. I am closing this bz as WONTFIX.

I will write a small script to roughly try to predict the memory usage on x86_64 and get it included in kexec-tools package using a separate bz.

Please re-open the bz if you don't agree with the conclusion.

"I will write a small script to roughly try to predict the memory usage on
x86_64 and get it included in kexec-tools package using a separate bz."

Please include here that bz number, so we can track it for our customers.  There are multiple customer facing tickets attached to this bug and they are going to want to know were we are on the status of this issue.

I have not opened any bz for that yet. In fact after thinking a more about it, in the first step i will tweak crashkernel=auto logic a bit so that many of the customers get it right automatically without doing anything.

Script will be useful once we have the capability to look into cusotomer's kdump.conf and try to predict memory usage based on that. That is hard and error prone. So for the time being I just plan to tweak crashkernel=auto on x86_64 so that it tries to get it right out of the box for majority of the systems.

Still there are no gurantees and more memory might be required based on system configuration or based on changed kdump.conf settings of user. So a customer should still test kdump to make sure reserved amount of memory is sufficient.