Bug 608683 - Dynamically adjust kdump reserved memory suggestion based on memory consumed by kernel
Summary: Dynamically adjust kdump reserved memory suggestion based on memory consumed ...
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kexec-tools (Show other bugs)
(Show other bugs)
Version: 6.0
Hardware: All Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Vivek Goyal
QA Contact: Chao Ye
URL:
Whiteboard:
Keywords: FutureFeature, Triaged
: 656047 (view as bug list)
Depends On:
Blocks: 656047
TreeView+ depends on / blocked
 
Reported: 2010-06-28 13:31 UTC by Vivek Goyal
Modified: 2018-11-14 13:42 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-09 19:49:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to dynamically adjust firstboot memory reservation based on usage in kernel (1.79 KB, patch)
2010-06-28 19:53 UTC, Neil Horman
no flags Details | Diff

Description Vivek Goyal 2010-06-28 13:31:27 UTC
Description of problem:

Currently firstboot suggests a default kdump memory reservation amount based on some static arch specific parameters. It could be improved to also take into account the memory consumed by currently booted kernel. And if currently booted kenrel has consumed more than 60-70% of reserved memory, it might make sense to 
automatically bump up the suggested value to user.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 3 RHEL Product and Program Management 2010-06-28 14:02:53 UTC
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.

Comment 4 Neil Horman 2010-06-28 19:53:59 UTC
Created attachment 427496 [details]
patch to dynamically adjust firstboot memory reservation based on usage in kernel

Comment 5 Neil Horman 2010-07-01 18:37:20 UTC
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

Comment 11 Neil Horman 2010-08-02 14:06:52 UTC
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!

Comment 13 Neil Horman 2010-11-23 11:50:55 UTC
*** Bug 656047 has been marked as a duplicate of this bug. ***

Comment 21 Vivek Goyal 2011-08-02 18:34:54 UTC
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.

Comment 22 Vivek Goyal 2011-08-09 19:49:03 UTC
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.

Comment 23 Jason Willeford 2011-08-10 13:45:33 UTC
"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.

Comment 24 Vivek Goyal 2011-08-10 16:09:15 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.