This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] Read memory in multiple lines in dcache_xfer_memory.


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 (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]