[Top] [All Lists]

Re: hangs running dbench with 16 clients

To: Nicholas Wourms <nwourms@xxxxxxxxxxxxx>
Subject: Re: hangs running dbench with 16 clients
From: Andi Kleen <ak@xxxxxxx>
Date: Thu, 19 Jun 2003 22:31:59 +0200
Cc: Andi Kleen <ak@xxxxxxx>, Steven Pratt <slpratt@xxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <3EF2198F.2000700@myrealbox.com>
References: <3EF1C932.4080706@austin.ibm.com> <1056034152.1772.92.camel@jen.americas.sgi.com> <3EF1D6AA.4050200@austin.ibm.com> <1056037205.1773.101.camel@jen.americas.sgi.com> <20030619195239.GB13952@wotan.suse.de> <3EF2198F.2000700@myrealbox.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
> Well that's all fine & good if you have the extra dumb (or not-so-dumb) 
> terminals lying around to use it, but not everyone does.  Furthermore, 
> getting things "set-up" for kgdb is just a PITA compared to kdb just 
> working as OOOPS happen (again, who wants to dedicate a machine to kgdb 
> full-time?).  Perhaps what might be done is to merge the two debuggers 

For oopses crash dumps are actually more practical. 

You have two main use cases: 
- Serious debugging of broken code. Nothing can beat source level
here, assembly level is just a pita.
- Post Mortem Analysis after a crash
Tools like crash or lkcd do this quite well, with less overhead.

kdb sits somewhere inbetween, but does nothing well.

> to give the user the choice of in-kernel debugging or remote core 
> debugging.  In other words, make the debugging of ooops/panics a boot 
> argument?  I don't know much about kgdb, so as to how practical this 
> might be is another question.

It's not practical. kdb is much more complex than kgdb.

There used to be a user land proxy to run kdb from kgdb, but it never 
worked really well and the latest kgdb stubs are much more powerful.

-Andi (who worked on a KDB port to another architecture, but gave up
and switched to kgdb because implementing dwarf2 unwinding in the kernel is 
just too ugly) 

<Prev in Thread] Current Thread [Next in Thread>