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". Daniel. _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
