public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Yao Qi <yao@codesourcery.com>
To: Pedro Alves <palves@redhat.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 6/8] linux-nat.c: better starvation avoidance, handle non-stop mode too
Date: Wed, 07 Jan 2015 07:06:00 -0000	[thread overview]
Message-ID: <8761cjul2b.fsf@codesourcery.com> (raw)
In-Reply-To: <1419625871-28848-7-git-send-email-palves@redhat.com> (Pedro	Alves's message of "Fri, 26 Dec 2014 20:31:09 +0000")

Pedro Alves <palves@redhat.com> writes:

> 3) If multiple threads hit a breakpoint, we report one of those, and
> "cancel" the others.  Cancelling means decrementing the PC, and
> discarding the event.  If the next time the LWP is resumed the
> breakpoint is still installed, the LWP should hit it again, and we'll
> report the hit then.  The problem I found is that this delays threads
> from advancing too much, with the kernel potentially ending up
> scheduling the same threads over and over, and others not advancing.

Sorry, I don't fully understand what is the problem.  Can you elaborate?
Is it something like GDB gets an event of thread foo, and events from
other threads aren't interesting.  GDB cancels them, but when GDB
resumes them, kernel always schedules thread foo.

> So the patch switches away from cancelling the breakpoints, and
> instead remembering that the LWP had stopped for a breakpoint.  If on
> resume the breakpoint is still installed, we report it.  If it's no
> longer installed, we discard the pending event then.  This is actually

Does "breakpoint is installed" indicate "target is still running"? then,
we report the event.  Otherwise, "target is stopped", we discard the
pending event.  Is that correct?

> @@ -2453,7 +2482,9 @@ stop_wait_callback (struct lwp_info *lp, void *data)
>    return 0;
>  }
>  
> -/* Return non-zero if LP has a wait status pending.  */
> +/* Return non-zero if LP has a wait status pending.  Discard the
> +   pending event and resume the LWP if the event that originally
> +   caused the stop became uninteresting.  */
>  
>  static int
>  status_callback (struct lwp_info *lp, void *data)

Probably, we should rename status_callback to something more meaningful.

> @@ -2523,16 +2601,19 @@ select_event_lwp_callback (struct lwp_info *lp, void *data)
>  
>    gdb_assert (selector != NULL);
>  
> -  /* Select only resumed LWPs that have a SIGTRAP event pending.  */
> -  if (lp->resumed && linux_nat_lp_status_is_event (lp))
> +  /* Select only resumed LWPs that have an event pending.  */
> +  if (lp->resumed && lwp_status_pending_p (lp))
>      if ((*selector)-- == 0)
>        return 1;

Do we need to do the same change in count_events_callback?  IMO, the
condition in both count_events_callback and select_event_lwp_callback
should be consistent.

-- 
Yao (齐尧)

  reply	other threads:[~2015-01-07  7:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-26 20:31 [PATCH 0/8] Linux: starvation avoidance in non-stop mode Pedro Alves
2014-12-26 20:31 ` [PATCH 1/8] gdb.threads/{siginfo-thread.c,watchthreads-reorder.c,ia64-sigill.c} races with GDB Pedro Alves
2015-01-06  6:20   ` Yao Qi
2014-12-26 20:31 ` [PATCH 2/8] watch_thread_num.exp and targets with fairer event reporting Pedro Alves
2014-12-26 20:31 ` [PATCH 3/8] cleanup and speed up (software_)breakpoint_inserted_here_p Pedro Alves
2014-12-26 20:32 ` [PATCH 4/8] linux-nat.c: clean up pending status checking and resuming LWPs Pedro Alves
2015-01-06  8:12   ` Yao Qi
2015-01-07 13:22     ` Pedro Alves
2015-01-07 14:10       ` Yao Qi
2014-12-26 20:32 ` [PATCH 7/8] [gdbserver] linux-low.c: better starvation avoidance, handle non-stop mode too Pedro Alves
2014-12-26 20:32 ` [PATCH 6/8] linux-nat.c: " Pedro Alves
2015-01-07  7:06   ` Yao Qi [this message]
2015-01-07 13:22     ` Pedro Alves
2015-01-07 14:08       ` Yao Qi
2015-01-07 14:36         ` Pedro Alves
2014-12-26 20:32 ` [PATCH 5/8] linux-nat.c: always mark execing LWP as resumed Pedro Alves
2014-12-26 20:32 ` [PATCH 8/8] add non-stop test that stresses thread starvation issues Pedro Alves
2015-04-02 14:53   ` Yao Qi
2015-04-06 11:26     ` Pedro Alves
2015-04-07 10:10       ` Yao Qi
2015-04-07 10:22         ` Pedro Alves
2015-04-07 10:31           ` Yao Qi
2015-01-09 15:07 ` [PATCH 0/8] Linux: starvation avoidance in non-stop mode Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8761cjul2b.fsf@codesourcery.com \
    --to=yao@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).