This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/2] Read memory in multiple lines in dcache_xfer_memory.
- From: Yao Qi <yao at codesourcery dot com>
- To: Doug Evans <dje at google dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Tue, 22 Oct 2013 08:48:30 +0800
- Subject: Re: [PATCH 2/2] Read memory in multiple lines in dcache_xfer_memory.
- Authentication-results: sourceware.org; auth=none
- References: <1382066466-2551-1-git-send-email-yao at codesourcery dot com> <1382066466-2551-3-git-send-email-yao at codesourcery dot com> <21093 dot 37082 dot 516044 dot 631275 at ruffy dot mtv dot corp dot google dot com>
On 10/22/2013 04:38 AM, Doug Evans wrote:
While I understand the improvement is nice, it does add complexity to the code.
[I'm not suggesting this patch isn't justified.
But I think we do need to weigh complexity vs actual speed-ups, and
Agreed. The code is more complex than I expected. It takes me two days
to fix a bug.
I'm in the "Need more data." state at the moment.]
The data for cache line sizes less than the default (64 bytes)
is nice but not compelling.
E.g., What if we just increase the cache line size to 256, say?
Or 1024? And/or maybe auto-adjust it based on
In this case, it is useful to increase the cache line size. Increase
the cache line size to 256 can save 0.1 (1.16 -> 1.06) in my experiment,
which is a good improvement.
When people are doing remote debugging, and find it is slow. The reason
of slowness is usually unclear, so it may not be useful advise them to
increase data cache line size.
"remote memory-read-packet-size" or some such?
"remote memory-read-packet-size" is not useful in this case, I am
afraid. GDB reads one data cache line by a single 'm' packet, and the
size (data cache line size) is less than the memory read packet size.
Changing "remote memory-read-packet-size" doesn't have effects.
--
Yao (éå)