[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