Enable kernel dump options on most architectures.

[markj]

Test Plan

Will do a tinderbox build.

[manu]

It seems that dump on arm64 currently doesn't work so I can't say if any of this options will be a benefit or not on this platform.

[markj]

In D15465#326427, @manu wrote:

It seems that dump on arm64 currently doesn't work so I can't say if any of this options will be a benefit or not on this platform.

Hopefully that'll be fixed before 12.0?

[rgrimes]

Can we not split KDB and DDB with NETDUMP?
Ie, put it after the options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
would keep all the KDB, GDB, DDB, etc in one lump, followed by dumping stuff, perhaps with one line of white space

[markj]

In D15465#326440, @rgrimes wrote:

Can we not split KDB and DDB with NETDUMP?
Ie, put it after the options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
would keep all the KDB, GDB, DDB, etc in one lump, followed by dumping stuff, perhaps with one line of white space

Wouldn't that make it look like the "turn off in stable branch" comment applies to the new options? Or am I misunderstanding your suggestion?

[rgrimes]

In D15465#326442, @markj wrote:

In D15465#326440, @rgrimes wrote:

Can we not split KDB and DDB with NETDUMP?
Ie, put it after the options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
would keep all the KDB, GDB, DDB, etc in one lump, followed by dumping stuff, perhaps with one line of white space

Wouldn't that make it look like the "turn off in stable branch" comment applies to the new options? Or am I misunderstanding your suggestion?

That would be a good reason to seperate it with a blank line. Why I am asking to move it this seems to split the "Debugging Support" and "Full Debugging Support" part of the config with the "Dump". I suppose one could say that dump is part of debugging support, but I think dump as more of a post failure analysis tool, rather than KDB/DDB/GDB which are active online debugging support.

[markj]

In D15465#326443, @rgrimes wrote:

In D15465#326442, @markj wrote:

In D15465#326440, @rgrimes wrote:

Can we not split KDB and DDB with NETDUMP?
Ie, put it after the options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
would keep all the KDB, GDB, DDB, etc in one lump, followed by dumping stuff, perhaps with one line of white space

Wouldn't that make it look like the "turn off in stable branch" comment applies to the new options? Or am I misunderstanding your suggestion?

That would be a good reason to seperate it with a blank line. Why I am asking to move it this seems to split the "Debugging Support" and "Full Debugging Support" part of the config with the "Dump". I suppose one could say that dump is part of debugging support, but I think dump as more of a post failure analysis tool, rather than KDB/DDB/GDB which are active online debugging support.

"post failure analysis" seems like a fancy term for a specific type of debugging, but I'm fine with moving it.

[markj]

Move options into a separate block.

[rgrimes]

Thanks

[rpokala]

It looks like the GENERIC configs that you're not updating are for ARM, RISC-V, and PPC64. Why are they being excluded?

[cem]

In D15465#326491, @rpokala wrote:

It looks like the GENERIC configs that you're not updating are for ARM, RISC-V, and PPC64. Why are they being excluded?

PPC64 is not excluded. That's powerpc/conf/GENERIC64.

ARM, MIPS, and RISC-V are excluded. Probably because GENERIC doesn't really exist on these platforms? Possibly also because these are low performance, low memory systems, where the CPU overhead of compression is more expensive, kernel text size is more expensive, and dump sizes are smaller relative to disk size (or there is no writable dump partition at all).

[rpokala]

In D15465#326493, @cem wrote:

In D15465#326491, @rpokala wrote:

It looks like the GENERIC configs that you're not updating are for ARM, RISC-V, and PPC64. Why are they being excluded?

PPC64 is not excluded. That's powerpc/conf/GENERIC64.

<Blink> Time for new glasses. :-/

ARM, MIPS, and RISC-V are excluded. Probably because GENERIC doesn't really exist on these platforms?

They might not be super useful by themselves, but they do exist.

Possibly also because these are low performance, low memory systems, where the CPU overhead of compression is more expensive, kernel text size is more expensive, and dump sizes are smaller relative to disk size (or there is no writable dump partition at all).

That's a reasonable answer. I just wanted to make sure it wasn't due to an oversight. Please note that when you commit.

[markj]

In D15465#326494, @rpokala wrote:

In D15465#326493, @cem wrote:

Possibly also because these are low performance, low memory systems, where the CPU overhead of compression is more expensive, kernel text size is more expensive, and dump sizes are smaller relative to disk size (or there is no writable dump partition at all).

That's a reasonable answer. I just wanted to make sure it wasn't due to an oversight. Please note that when you commit.

There's a fairly strong argument to be made for enabling netdump on such platforms, but until someone has done some testing and added support for some common NIC drivers on such platforms (mge(4)?), I'm not planning on enabling it.

[manu]

Ok for me on arm64, dump is in zstd format and compress ok (kgdb coredump but it does it too for standard dumps so the issue is elsewhere)