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/