[OB PATCH] Improve remote attach round-trips without btrace

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[OB PATCH] Improve remote attach round-trips without btrace

Conrad Meyer
Hello list,

For remotes which do not support 'qXfer:btrace-conf:read', we can save
several round trips for each thread.  This is especially significant
when your remote is a kernel with 100s or 1000s of threads and latency
is intercontinental.

Without the change, with target, remote, and infrun debugging enabled,
one might see:

    Sending packet: $Hg18aee#43...Ack
    Packet received: OK
    Sending packet: $Hg186f7#eb...Ack
    Packet received: OK
    remote:target_xfer_partial (24, , 0x805454000, 0x0, 0x0, 4096) = -1, 0

(Repeated for all non-exited threads.)

What's happening here is that remote_target::remote_btrace_maybe_reopen is:
  * walking all non-exited threads
  * for each, invoking set_general_thread () ("HgNNNNN" packet sent to remote)
  * btrace_config is initialized to zero with memset
  * btrace_read_config -> ... -> remote_target::remote_read_qxfer
checks if PACKET_qXfer_btrace_conf is disabled, and does not send any
packet; does not modify btrace_config
  * (The same check results in the "remote:target_xfer_partial (...) =
-1" error return printed with debugging enabled)
  * Finally, the 'format == BTRACE_FORMAT_NONE' condition
short-circuits the loop with 'continue' because BTRACE_FORMAT_NONE
happens to have a zero value, matching the earlier memset.

With the change, if the remote does not specify
'qXfer:btrace-conf:read+' in qSupported stub features, these spurious
thread switches are avoided.

Empirically, this improves "target remote" attach time on a particular
real-world configuration with ~770 threads from ~2 minutes to ~4
seconds:

$ ministat control.dat test.dat
x control.dat
+ test.dat
+--------------------------------------------------------------------------+
|+                                                                        x|
|+                                                                        x|
|+                                                                        x|
|A                                                                        A|
+--------------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   3        117.58        117.99        117.84     117.80333    0.20744477
+   3           4.2          4.22          4.21          4.21          0.01
Difference at 95.0% confidence
        -113.593 +/- 0.332863
        -96.4262% +/- 0.0169361%
        (Student's t, pooled s = 0.146856)

Please find the 'git format-patch' formatted patch attached to this
email, and please let me know if you have any follow-up questions.  I
have already sent a copyright disclaimer form email for this change to
assign@gnu.

Thanks,
Conrad

P.S., I am not subscribed to the list.

gdb/ChangeLog:

* remote.c (remote_target::remote_btrace_maybe_reopen): Avoid
unnecessary thread walk if remote doesn't support the packet.

gdb.btrace.0.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [OB PATCH] Improve remote attach round-trips without btrace

Pedro Alves-7
On 8/19/19 8:18 PM, Conrad Meyer wrote:

> Please find the 'git format-patch' formatted patch attached to this
> email, and please let me know if you have any follow-up questions.  I
> have already sent a copyright disclaimer form email for this change to
> assign@gnu.

Thanks, this looks good.  

I don't see your assignment/disclaimer in fencepost yet, but given that
change is small, that should not be a problem, so I went ahead and
merged it.

Pedro Alves
Reply | Threaded
Open this post in threaded view
|

Re: [OB PATCH] Improve remote attach round-trips without btrace

Conrad Meyer
On Tue, Aug 20, 2019 at 7:28 AM Pedro Alves <[hidden email]> wrote:

>
> On 8/19/19 8:18 PM, Conrad Meyer wrote:
>
> > Please find the 'git format-patch' formatted patch attached to this
> > email, and please let me know if you have any follow-up questions.  I
> > have already sent a copyright disclaimer form email for this change to
> > assign@gnu.
>
> Thanks, this looks good.
>
> I don't see your assignment/disclaimer in fencepost yet, but given that
> change is small, that should not be a problem, so I went ahead and
> merged it.

Thanks, Pedro!

Best,
Conrad