On 8/24/20 10:19 AM, Bhupesh Sharma wrote:
Hi Lianbo,
On Wed, Aug 19, 2020 at 2:23 PM Dave Young <dyoung(a)redhat.com> wrote:
>
> Hi Lianbo,
> On 08/12/20 at 02:32pm, Lianbo Jiang wrote:
>> Sometimes, debugging the kdump service failure becomes very challenging
>> because there is no complete debugging information, which requires
>> modification of the options or the scripts like kdumpctl, mkdumprd, etc
>> to collect the information for troubleshooting.
>>
>> That means users have to wait for the next failure so that they can
>> capture the additional information, which could waste valuable time.
>>
>> This patch series will add the debugging messages and save them to a
>> file. It includes the following patches:
>>
>> [1] [PATCH 1/2] kdumpctl/mkdumprd: add 'set -x' to output debugging
>> information to a file
>> [2] [PATCH 2/2] kdumpctl: add the '-d' option to enable the kexec
loading
>> debugging messages
>
> [2] should be good, but for [1], I'm not sure if this can make kdump
> service startup even slower. Have you compared the performance
> with/without the change?
I agree with Dave's comment above. I am particularly worried about the
arm64 systems which take a lot of time when MMU is turned off during
kdump relocation (for e.g. the thunderx2 systems).
I have a couple of suggestions:
- Let's keep a option to enable or disable this logging - not every
user would like to enable this 'additional' debug information (log
file creation) by default. So how about providing and additional
parameter in the kdump configuraiton file(s) to see if this has been
enabled explicitly by user. kdumpctl can accordingly enable the '-x'
debug flag.
I like the idea of having an additional parameter in the kdump configuration
file to enable and disable the kdumpctl (mkdumprd/kexec load etc.) debug log
on-demand. If the test results reveal that the overhead of this debug option
is negligible then set it to "enabled" by default else set it to
"disabled".
If the overhead is significantly high then it may also impact the *overall*
system's boot time.
The suggestion to keep the debug log *enabled* by default is to ensure that
we capture the addition debug log of any error/problem in the first attempt.
--
Buland