Planned availability of SGI kdb and lkcd in future 2.4 vendor dis tributions

[Keith Owens]

On Thu, 7 Sep 2000 15:33:20 -0700 (PDT), 
Scott Lurndal <slurn at nanobiz.com> wrote:
>Being that there is no additional overhead (aside from some small number
>of kb of code) when KDB is included in a production kernel, it is nice
>to have on all the time - just in case the system does panic or hang
>due to a heisenbug.

It does introduce overhead on some common paths.

* NMI handling checks for a kdb vector, NMI code is driven once per
  timer tick on each cpu if the NMI oopser is active (which it should
  be).

* The serial code has to check for kdb interrupt keys.

* The frame pointer option adds extra code to some assembler code like
  semaphore and spin lock out of line code.

* The register spill affect of maintaining frame pointers on ix86 is
  noticable, fortunately kdb v1.3 works without frame pointers so I
  normally run without CONFIG_FRAME_POINTER.

* kdb has a longer section of code for the page fault handler, we have
  to handle last branch recording around the page fault code.  This is
  the one that worries me the most as far as performance goes.

* kdb needs kallsyms to get kernel and module symbols.  kallsyms adds
  20-30% to the size of the loaded kernel.

* The main kdb code itself increases the size of the kernel, although
  this is swamped by the size of kallsyms.