Re: RDI code busy-waiting on running target?

Re: RDI code busy-waiting on running target?

[Grant Edwards]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Thu, Jul 11, 2002 at 05:58:56PM -0500, Grant Edwards wrote:

> I've noticed that gdb uses all the CPU it can get while the
> target is running (e.g. busy-waiting 'till target stops).
> 
> I'm building 5.2 to see if it still does that

Yup.  

Here's a patch that fixes it.  I only added the usleep() when
there's no ui_loop_hook to call.  Is that the right thing to
do, or will Insight et al still suck CPU time?  I'm not sure
who's supposed to be surrendering the CPU, the UI or the
target.

Is usleep() portable?

-- 
Grant Edwards
grante@visi.com

[-- Attachment #2: rdi-busy-wait.patch --]
[-- Type: text/plain, Size: 1296 bytes --]

diff -r -U8 gdb-5.2/gdb/ChangeLog gdb-5.2-mod/gdb/ChangeLog
--- gdb-5.2/gdb/ChangeLog	Fri Apr 26 20:05:21 2002
+++ gdb-5.2-mod/gdb/ChangeLog	Thu Jul 11 18:39:18 2002
@@ -1,8 +1,14 @@
+2002-09-11  Grant Edwards <grante@visi.com>
+
+        * rdi-share/ardi.c: add 10ms sleep (iff there's no
+          ui_loop_hook) to busy-wait loop when target is
+          running.
+
 2002-04-26  GDB Administrator  <gdbadmin@sourceware.cygnus.com>
 
 	GDB 5.2 Released.
 	* version.in: Update to version 5.2.
 
 2002-04-26  Michal Ludvig  <mludvig@suse.cz>
 
 	* x86-64-tdep.c (x86_64_skip_prologue): Print note when debugging
Only in gdb-5.2-mod/gdb: ChangeLog~
diff -r -U8 gdb-5.2/gdb/rdi-share/ardi.c gdb-5.2-mod/gdb/rdi-share/ardi.c
--- gdb-5.2/gdb/rdi-share/ardi.c	Thu Oct 12 17:56:31 2000
+++ gdb-5.2-mod/gdb/rdi-share/ardi.c	Thu Jul 11 18:28:58 2002
@@ -1411,16 +1411,18 @@
   interrupt_request = FALSE;
   stop_request = FALSE;
   
   signal(SIGINT, ardi_sigint_handler);
   while( executing )
   {
     if (ui_loop_hook)
       ui_loop_hook(0);
+    else
+      usleep(10000);
     
     if (interrupt_request || stop_request)
       {
         interrupt_target();
         interrupt_request = FALSE;
         stop_request = FALSE;
       }
     Adp_AsynchronousProcessing( async_block_on_nothing );

Re: RDI code busy-waiting on running target?

[Keith Seitz]

On Thu, 11 Jul 2002, Grant Edwards wrote:

> Here's a patch that fixes it.  I only added the usleep() when
> there's no ui_loop_hook to call.  Is that the right thing to
> do, or will Insight et al still suck CPU time?  I'm not sure
> who's supposed to be surrendering the CPU, the UI or the
> target.

Insight would definitely shoot to 100% CPU, too. This often a problem with
have gdb non-event based w.r.t. the target. I would recommend doing the
sleep for the ui_loop_hook, too.

Keith

Re: RDI code busy-waiting on running target?

[Grant Edwards]

On Thu, Jul 11, 2002 at 04:53:39PM -0700, Keith Seitz wrote:
> On Thu, 11 Jul 2002, Grant Edwards wrote:
>
> > Here's a patch that fixes it.  I only added the usleep() when
> > there's no ui_loop_hook to call.  Is that the right thing to
> > do, or will Insight et al still suck CPU time?  I'm not sure
> > who's supposed to be surrendering the CPU, the UI or the
> > target.
> 
> Insight would definitely shoot to 100% CPU, too. This often a problem with
> have gdb non-event based w.r.t. the target. I would recommend doing the
> sleep for the ui_loop_hook, too.

I'll submit a replacement patch tomorrow.

-- 
Grant Edwards
grante@visi.com

Re: RDI code busy-waiting on running target?

[Grant Edwards]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On Thu, Jul 11, 2002 at 06:43:43PM -0500, Grant Edwards wrote:

> > I've noticed that gdb uses all the CPU it can get while the
> > target is running (e.g. busy-waiting 'till target stops).
>
> Here's a patch that fixes it.

Here's a new version of the patch that does the sleep
unconditionally and uses select() instead of usleep().

-- 
Grant Edwards
grante@visi.com

[-- Attachment #2: rdi-busy-wait.patch --]
[-- Type: text/plain, Size: 1211 bytes --]

diff -r -U8 gdb-5.2-orig/gdb/ChangeLog gdb-5.2/gdb/ChangeLog
--- gdb-5.2-orig/gdb/ChangeLog	Fri Apr 26 20:05:21 2002
+++ gdb-5.2/gdb/ChangeLog	Fri Jul 12 10:22:38 2002
@@ -1,8 +1,13 @@
+2002-07-11  Grant Edwards <grante@visi.com>
+
+        * rdi-share/ardi.c: add 10ms sleep to busy-wait loop
+        when target is running.
+
 2002-04-26  GDB Administrator  <gdbadmin@sourceware.cygnus.com>
 
 	GDB 5.2 Released.
 	* version.in: Update to version 5.2.
 
 2002-04-26  Michal Ludvig  <mludvig@suse.cz>
 
 	* x86-64-tdep.c (x86_64_skip_prologue): Print note when debugging
diff -r -U8 gdb-5.2-orig/gdb/rdi-share/ardi.c gdb-5.2/gdb/rdi-share/ardi.c
--- gdb-5.2-orig/gdb/rdi-share/ardi.c	Thu Oct 12 17:56:31 2000
+++ gdb-5.2/gdb/rdi-share/ardi.c	Fri Jul 12 10:17:37 2002
@@ -1409,16 +1409,20 @@
 #endif
 
   interrupt_request = FALSE;
   stop_request = FALSE;
   
   signal(SIGINT, ardi_sigint_handler);
   while( executing )
   {
+    struct timeval timeout = {0,10000};
+
+    select(0,0,0,0,&timeout);
+    
     if (ui_loop_hook)
       ui_loop_hook(0);
     
     if (interrupt_request || stop_request)
       {
         interrupt_target();
         interrupt_request = FALSE;
         stop_request = FALSE;

Re: RDI code busy-waiting on running target?

[Grant Edwards]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Fri, Jul 12, 2002 at 10:26:53AM -0500, Grant Edwards wrote:
> > I've noticed that gdb uses all the CPU it can get while the
> > target is running (e.g. busy-waiting 'till target stops).
>
> Here's a patch that fixes it.

Thanks to Dan Kegel for pointing out that an auto struct with
initializer isn't kosher.  One more try...

-- 
Grant Edwards
grante@visi.com

[-- Attachment #2: rdi-busy-wait.patch --]
[-- Type: text/plain, Size: 1254 bytes --]

diff -r -U8 gdb-5.2-orig/gdb/ChangeLog gdb-5.2/gdb/ChangeLog
--- gdb-5.2-orig/gdb/ChangeLog	Fri Apr 26 20:05:21 2002
+++ gdb-5.2/gdb/ChangeLog	Fri Jul 12 10:22:38 2002
@@ -1,8 +1,13 @@
+2002-07-11  Grant Edwards <grante@visi.com>
+
+        * rdi-share/ardi.c: add 10ms sleep to busy-wait loop
+        when target is running.
+
 2002-04-26  GDB Administrator  <gdbadmin@sourceware.cygnus.com>
 
 	GDB 5.2 Released.
 	* version.in: Update to version 5.2.
 
 2002-04-26  Michal Ludvig  <mludvig@suse.cz>
 
 	* x86-64-tdep.c (x86_64_skip_prologue): Print note when debugging
diff -r -U8 gdb-5.2-orig/gdb/rdi-share/ardi.c gdb-5.2/gdb/rdi-share/ardi.c
--- gdb-5.2-orig/gdb/rdi-share/ardi.c	Thu Oct 12 17:56:31 2000
+++ gdb-5.2/gdb/rdi-share/ardi.c	Fri Jul 12 13:03:35 2002
@@ -1409,16 +1409,22 @@
 #endif
 
   interrupt_request = FALSE;
   stop_request = FALSE;
   
   signal(SIGINT, ardi_sigint_handler);
   while( executing )
   {
+    struct timeval timeout;
+    timeout.tv_sec = 0;
+    timeout.tv_usec = 10000;
+
+    select(0,0,0,0,&timeout);
+    
     if (ui_loop_hook)
       ui_loop_hook(0);
     
     if (interrupt_request || stop_request)
       {
         interrupt_target();
         interrupt_request = FALSE;
         stop_request = FALSE;

Re: RDI code busy-waiting on running target?

[Andrew Cagney]

> +    struct timeval timeout;
> +    timeout.tv_sec = 0;
> +    timeout.tv_usec = 10000;
> +
> +    select(0,0,0,0,&timeout);
> +    

Doing a select on nothing strikes me as wrong.  How is this code 
detecting that something is ``ready''?

Andrew

Re: RDI code busy-waiting on running target?

[Momchil Velikov]

>>>>> "Andrew" == Andrew Cagney <ac131313@ges.redhat.com> writes:

>> +    struct timeval timeout;
>> +    timeout.tv_sec = 0;
>> +    timeout.tv_usec = 10000;
>> +
>> +    select(0,0,0,0,&timeout);
>> +

Andrew> Doing a select on nothing strikes me as wrong.  How is this code
Andrew> detecting that something is ``ready''?

Timeout.  AFAIK, the only option for high-resolution sleep in systems
lacking ``nanosleep''.

~velco

Re: RDI code busy-waiting on running target?

[Andrew Cagney]

> "Andrew" == Andrew Cagney <ac131313@ges.redhat.com> writes:
> 
> 
>>> +    struct timeval timeout;
>>> +    timeout.tv_sec = 0;
>>> +    timeout.tv_usec = 10000;
>>> +
>>> +    select(0,0,0,0,&timeout);
>>> +
> 
> 
> Andrew> Doing a select on nothing strikes me as wrong.  How is this code
> Andrew> detecting that something is ``ready''?
> 
> Timeout.  AFAIK, the only option for high-resolution sleep in systems
> lacking ``nanosleep''.

If it is a timeout, it should be waiting for min (time until next 
timeout, gui keep alive delta).

Andrew

Re: RDI code busy-waiting on running target?

[Grant Edwards]

On Sun, Jul 14, 2002 at 02:01:27PM -0400, Andrew Cagney wrote:
> > "Andrew" == Andrew Cagney <ac131313@ges.redhat.com> writes:

> >>> +    struct timeval timeout;
> >>> +    timeout.tv_sec = 0;
> >>> +    timeout.tv_usec = 10000;
> >>> +
> >>> +    select(0,0,0,0,&timeout);
> > 
> > Andrew> Doing a select on nothing strikes me as wrong.  How is this code
> > Andrew> detecting that something is ``ready''?

It has no way of knowing.  That's the whole problem.  There is
no way: it's a busy-wait polling loop.

> > Timeout.  AFAIK, the only option for high-resolution sleep in systems
> > lacking ``nanosleep''.
> 
> If it is a timeout, it should be waiting for min (time until next 
> timeout, gui keep alive delta).

Sorry, I've no idea what that means.  Care to explain?

If you want the wait to be for some value other than 10ms,
that's fine with me.  I was trying to make the mininum change
possible while still meeting my goal of not sucking up all of
the CPU time.  How long do you want it? 20ms? 50ms? 100ms?

Much longer than 100ms is probably going to be noticable.

-- 
Grant Edwards
grante@visi.com

Re: RDI code busy-waiting on running target?

[Andrew Cagney]

>> If it is a timeout, it should be waiting for min (time until next 
>> timeout, gui keep alive delta).
> 
> 
> Sorry, I've no idea what that means.  Care to explain?
> 
> If you want the wait to be for some value other than 10ms,
> that's fine with me.  I was trying to make the mininum change
> possible while still meeting my goal of not sucking up all of
> the CPU time.  How long do you want it? 20ms? 50ms? 100ms?
> 
> Much longer than 100ms is probably going to be noticable.

The code appears to be implementing a timer using polling.  Something 
somewhere must know the intended timer frequency and hence the sleep 
should be the minimum of:

	-	time to next timer event
	-	frequency that gui wants control

Andrew

Re: RDI code busy-waiting on running target?

[Grant Edwards]

On Mon, Jul 15, 2002 at 12:31:23PM -0400, Andrew Cagney wrote:
> 
> >> If it is a timeout, it should be waiting for min (time until next 
> >> timeout, gui keep alive delta).
> > 
> > Sorry, I've no idea what that means.  Care to explain?

[...]

> The code appears to be implementing a timer using polling. 

The command-line UI or Insight?  (Are there any other linked-in
UIs?)

> Something somewhere must know the intended timer frequency and
> hence the sleep should be the minimum of:
> 
> 	-	time to next timer event
> 	-	frequency that gui wants control

Doh!  Now I see. I completely missed that the min ([...], [...])
was pseudo-code.  What do other targets do?  (I should go
look.)  10ms is the minimum practical delay under most of the
Linux or Linux-like OSes that I know about.  Longer is easier.
Shorter isn't.

-- 
Grant Edwards
grante@visi.com

RE: RDI code busy-waiting on running target?

[Dan Kegel]

Grant Edwards wrote:

> Is usleep() portable?

http://sarien.sourceforge.net/hackersguide/intro-portability.html
claims no.

It uses a timer on some platforms, too, so I'd avoid it anyway.

You might consider using select() with no fds to sleep briefly.  That's
tradition.

- Dan