[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Multicore Visualizer on 576 cores
|
Hi Marc,
[...]
>> Lessons learned:
>> (1) When gdb connects to this platform, he ask each core/thread individually
>> for his state. It's a bit slow...
> Are you talking about GDB itself, or of CDT? I'm wondering if you are describing
> a delay when GDB connects to the target and another delay when CDT requests
> information from GDB, or if there is one single delay from CDT to GDB?
It's not gdb itself. From command line, it's very fast.
>> (2) When visualizer connects, he does the same things: so we have to wait
>> twice longer.
> If the visualizer uses the DSF services, the caching mechanism should kick in
> and there should be no need to go back to GDB for the information that was
> already fetched.
I've seen that. I started to use the caching mechanism, and I gain a few time.
Note: I didn't found any documentation about DSF caching mechanism. Is it documented somewhere ?
>> Our gdb is able to return the state of the whole system with a single "info
>> thread" command.
>> I was able to use this feature to populate the multicore visualizer view faster
>> (much faster).
>>
>> However, I do not know how to use the feature to populate the standard
>> debug view. Any hints ?
> The debug view gets its information using the DSF services, mostly the IProcesses
> service. Overriding that one to use an enhanced 'info threads' is how you would
> improve this.
I think you hit the point. My implementation of IProcesses service is not optimal.
I will investigate further on this service.
Many thanks,
Xavier