On 12/22/22 17:49, Daniel Thompson wrote:
On Mon, Dec 19, 2022 at 11:11:07PM +0100, Helge Deller wrote:
On my 32-bit machine, with BREAK_INSTR_SIZE=4 the kgdb_break[] structure
allocates 16000 bytes of static kernel memory, which is - by default -
to be able to handle up to 1000 concurrent kgdb breakpoints. I might be
wrong, but I doubt that in real life someone really needs that many
breakpoints, so I suggest to reduce the number of possible kgdb
breakpoints and thus reduce the memory footprint of kgdb_break[].
I am somewhat dubious about this change. 1000 is large but if we place
a breakpoint on an inline function this can result in many breakpoints
being set (they appear as a single b.p. in the gdb UI but kgdb will see
all the inlined sites).
As such I'm not clear why 40 (which risks breaking some use cases) is a
better default than 1000 (which "only" costs us 16 to 24k).
If somebody really wants to debug a system where the memory costs cause
serious trouble then I guess we could entertain a config option
(defaulting to 1000) to allow for such tiny systems. However it does
need to start from "we really need this memory because..." rather than
just because "16k is a waste".
Saving memory is good, and choosing a sane and realistic high-enough default
value which keeps debugging possible should be the goal. I haven't debugged
much with kgdb yet, so I don't know what the best amount is.
40 was just a guess from me.
Helge
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
