Re: [PATCH] Improve performance of large restore commands

Pedro Alves
2013-07-25T17:59:42Z

On 07/25/2013 01:08 PM, Anton Blanchard wrote:
>
> 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.

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.

> We already cap reads to 4K

Where exactly? In the target backend, perhaps? I'm not finding a
cap at the target.c level.

> --
>
> 2013-07-25 Anton Blanchard <anton@samba.org>
>
> * target.c (target_write_with_progress): Cap write to 4K

Period at end of sentence.

>
> Index: b/gdb/target.c
> ===================================================================
> --- a/gdb/target.c
> +++ b/gdb/target.c
> @@ -2287,9 +2287,11 @@ target_write_with_progress (struct targe
>
> while (xfered < len)
> {
> + /* Cap the write to 4K */
> + int to_transfer = min(4096, len - xfered);
> LONGEST xfer = target_write_partial (ops, object, annex,

Empty line after last declaration. Missing space before parens.

> (gdb_byte *) buf + xfered,
> - offset + xfered, len - xfered);
> + offset + xfered, to_transfer);
>
> if (xfer == 0)
> return xfered;
>

--
Pedro Alves