Re: Linux Realtime Scheduling Option

[Dave Trollope <trollope@lucent.com>]

Hi Daniel,

Daniel Jacobowitz wrote:

>On Mon, Mar 21, 2005 at 01:20:02PM -0600, David Steven Trollope wrote:
>  
>
>>Hi Daniel,
>>
>>Our application does change its own priority, but I was concerned with 
>>the priority of gdbserver/gdb. Which Linux tools are you referring to? 
>>I'll go take a look at them.
>>    
>>
>
>Search for 'rt' or 'chrt'; I do not recall which one is current.  I
>believe they are in the 'schedutils' distribution.
>  
>
I'll take a look.

>>In our environment gdb/gdbserver should always run realtime at a set 
>>priority. Help me understand why is it not a good idea to have 
>>gdb/gdbserver set its own priority based on an option in .gdbinit?
>>    
>>
>
>First of all, gdbserver doesn't parse an init file.  You would have to
>add a Linux-specific packet type to the remote protocol for GDB to
>communicate this to gdbserver.
>  
>
I wasn't thinking this was Linux specific. Doesn't Solaris also have 
realtime extensions that this would apply to?

I can certainly see that its not generic enough to be worthy of adding 
to the remote protocol.


>Secondly, because there are standalone tools to handle the problem.
>gdbserver is supposed to be simple; I don't want to add code specific
>to a particular, fairly uncommon debugging environment when existing
>tools handle it perfectly well.
>
>If you can come up with a reason why the standalone tools can not be
>used to solve the problem, then we can rediscuss :-)
>  
>
Its not a gdbserver specific issue. If you run gdb on any Linux machine 
while loading an application that sets its own real time priority 
problems will likely occur from the mismatch. I don't know if Solaris 
suffers from the same issue, but I would expect it to.

I think its really applicable to any unix variant where realtime 
extentions allow an application to change its own priority.

Perhaps gdb/gdbserver could have a command line option (instead of 
.gdbinit) that registers itself realtime, as the highest priority? Its 
likely you want the debugger to run at the highest priority to catch 
tight loops etc. This would also map to non-unix OSs like VxWorks.

Does this strategy sound more appealing?

I appreciate your time.

Cheers
Dave