This is the mail archive of the 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/26/2013 01:08 AM, Doug Evans wrote:
If the cache line size is set based on the remote packet size (and all
else being equal, that's a reasonable thing to do),
then we don't have to tell them anything.
OTOH, I'm not entirely thrilled with changing the cache-line size automagically.

Data cache line size should be related to the pattern GDB reads target data, instead of remote packet size. Data cache is quite general, and we may not have to connect it with remote packet size.

"Setting cache line size based on the remote packet size" helps on performance, but IMO it is sort of different optimization from what I proposed here.

OTOOH, how many users even know that they*can*  change the cache line size?
We don't have to advise them to change the cache line size (with the
word "advise" implying the end result is necessarily an improvement),
but I'm totally ok with suggesting it as something to*try*.

Of course. However, I still prefer to get GDB smarter to avoid performance issues as much as possible :).

>>"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.
You misparsed what I wrote, sorry for being unclear.

Putting the sentence back together:
And/or maybe auto-adjust it based on "remote memory-read-packet-size"
or some such?
["it" being the cache line size]

When I connect to gdbserver on my amd64-linux box the cache line size
is 64 but the memory-read-packet-size is 16383.
Those are wildly different numbers.  I'm not suggesting setting the
cache line size to 16K, but it does suggest that 64 is a bit small.
OTOH, there's no point in having a 256 byte line size of the
memory-read-packet-size is 64.

Yeah, I agree that these two sizes should match each other to some extent.

OTOOH, with your patch to read multiple cache lines at once the cost
of smaller cache line sizes is mitigated.


Yao (éå)

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