Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Anton Blanchard <anton@samba.org>
To: Pedro Alves <palves@redhat.com>
Cc: Luis Machado <lgustavo@codesourcery.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Improve performance of large restore commands
Date: Mon, 29 Jul 2013 05:45:00 -0000	[thread overview]
Message-ID: <20130729154457.0e6e6bd7@kryten> (raw)
In-Reply-To: <51F16780.70408@redhat.com>


Hi Pedro,

Thanks for the review.

> > I noticed a large (100MB) restore took hours to complete. The
> > problem is target_xfer_partial repeatedly mallocs and memcpys the
> > entire 100MB buffer only to find a small portion of it is actually
> > written.
> 
> I think you meant memory_xfer_partial, in the breakpoint shadow
> handling, right?  I'd prefer pushing the capping close to the
> offending malloc/memcpy.

I wrote the summary after looking at the perf profile data. It is
indeed in memory_xfer_partial and to confirm I reran with a gdb
built with -fno-inline:

    memcpy |
                     --- memcpy
                         target_xfer_partial
                         target_write_with_progress
                         target_write_memory
                         restore_command

I've moved the check closer and also added a better comment as Luis
suggested. Updated patch below.

> We could conceivably change that shadowing algorithm to not malloc
> at all.  E.g., say, with a memory block like
> 
>   |------B------|
> start          end
> 
> with B being the address where a breakpoint is supposed to be planted,
> write block [start,B), then a write for the breakpoint instruction
> at B, then another block write for (B,e).
> 
> Or, we could throttle the requested window width up/down depending
> on the buffer size returned at each partial transfer.
> 
> I'm not actually suggesting doing this, only explaining why I'd
> rather put the cap close to the problem it solves.
> target_write_partial is used for other targets objects too, not just
> memory.

Yes, that definitely makes sense.

> > We already cap reads to 4K
> 
> Where exactly?  In the target backend, perhaps?  I'm not finding a
> cap at the target.c level.

I've removed this comment. I was looking at target_fileio_read_alloc_1
but it actually starts at 4K and doubles in size as it grows.

Anton
--

[PATCH] Improve performance of large restore commands

I noticed a large (100MB) restore took hours to complete. The problem
is memory_xfer_partial repeatedly mallocs and memcpys the entire
100MB buffer for breakpoint shadow handling only to find a small portion
of it is actually written.

The testcase that originally took hours now takes 50 seconds.

--

2013-07-29  Anton Blanchard  <anton@samba.org>

	* target.c (memory_xfer_partial): Cap write to 4K

Index: b/gdb/target.c
===================================================================
--- a/gdb/target.c
+++ b/gdb/target.c
@@ -1669,6 +1669,13 @@ memory_xfer_partial (struct target_ops *
       void *buf;
       struct cleanup *old_chain;
 
+      /* A large write request is likely to be partially satisfied
+	 by memory_xfer_partial_1. We will continually malloc
+	 and free a copy of the entire write request for breakpoint
+	 shadow handling even though we only end up writing a small
+	 subset of it. Cap writes to 4K to mitigate this.  */
+      len = min(4096, len);
+
       buf = xmalloc (len);
       old_chain = make_cleanup (xfree, buf);
       memcpy (buf, writebuf, len);


  reply	other threads:[~2013-07-29  5:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 12:09 Anton Blanchard
2013-07-25 17:30 ` Luis Machado
2013-07-25 17:59 ` Pedro Alves
2013-07-29  5:45   ` Anton Blanchard [this message]
2013-07-29 14:14     ` Pedro Alves
2013-07-29 23:25       ` Anton Blanchard
2013-07-30 11:33         ` Pedro Alves
2013-07-31 12:35           ` Anton Blanchard
2013-07-31 14:47             ` 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=20130729154457.0e6e6bd7@kryten \
    --to=anton@samba.org \
    --cc=gdb-patches@sourceware.org \
    --cc=lgustavo@codesourcery.com \
    --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