[Crash-utility] [RFC PATCH v2 0/2] Show memory overcommit data in dump_kmeminfo()
Aaron Tomlin
atomlin at redhat.com
Wed Dec 3 15:11:37 UTC 2014
On Tue 2014-12-02 12:11 -0500, Dave Anderson wrote:
> Hi Aaron,
>
> I've got a RHEL4 kernel which shows a COMMIT LIMIT of zero, and then
> dies with a SIGFPE:
[ ... ]
> Program received signal SIGFPE, Arithmetic exception.
> dump_kmeminfo () at memory.c:7970
> 7970 / allowed) : 0;
OK.
> So there also needs to be an allowance for this:
[ ... ]
> crash> p sysctl_overcommit_ratio
> sysctl_overcommit_ratio = $2 = 0
> crash>
Quick question, would you prefer to silently bail out of displaying memory
over commitment details in the event of a 0 value for "allowed" or print as
follows:
COMMIT LIMIT 0 0 ----
COMMITTED 1150595 4.4 GB ----
> Since kmem -i is such a commonly used command, any required offsets should
> be stored in the offset table, and not reinitialized every time it's called.
> Can you add atomic_t.counter and percpu_counter.count to the bottom of the
> offset_table() so that OFFSET() can be used? And for that matter, maybe have
> vm_init() initialize all of the hstate-related offsets in order to simplify
> dump_hstates() and get_hugetlb_total_pages() so that they only have to check
> for the validity of the sizes/offsets that they need instead of having to
> re-initialize them every time?
OK no problem will do.
> Also, is there a reason you made this change?:
>
> @@ -4627,7 +4628,7 @@ cmd_kmem(void)
>
> }
>
> - if (iflag == 1)
> + if (iflag)
> dump_kmeminfo();
>
> if (pflag == 1)
That was a mistake. I'll revert this change.
--
Aaron Tomlin
More information about the Crash-utility
mailing list