Re: arch_int_restore_interrupts
Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> Sun, 05 Aug 2007 03:30:29 +0200
| Newsgroups | gmane.os.openbeos.kernel.devel |
|---|---|
| Message-ID | <[email protected]> |
On 2007-08-05 at 02:21:37 [+0200], Salvatore Benedetto <[email protected]> wrote: > > Note, that heavy debug output may indeed make your system appear to make > > no > > more progress. The more common case is that it just becomes *really* slow. > > A rarer case, particularly when adding enough output in the interrupt > > handling code (i386_handle_trap()), is that you really manage to stall the > > system. > > So do you think that this behavior is due to heavy use of dprintf? That's hard to say. If the problem doesn't occur any longer, after you disable debug output, then it's pretty likely. In that case, if you mostly have interrupts enabled while calling dprintf() from your thread, you might indeed think about implementing the second dprintf() path, as it might improve the situation. Note, that our current scheduler seems to have a problem with higher priority threads starving lower priority ones. Doing a lot (that includes debug output) in a high priority thread can quite likely cause system blocking as you describe it. CU, Ingo ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/