On Wed, 20 May 2026, 12:21 Zane Leung, <[email protected]> wrote:
> > On 5/20/2026 6:00 PM, Antonio Borneo wrote: > > I can imagine that polling 80 cores takes time, eventually using all > > the time available just doing that. > > OpenOCD doesn't have a command to change the polling interval; it it > > hardcoded in file src/target/target.h in ms units > > #define TARGET_DEFAULT_POLLING_INTERVAL 100u > > > > The polling is there only to understand if the target state is changed > > from running to halt. > > If you change it 1000 ms or more you would probably get better > > debugging performance. > > If this really works, adding a new command e.g. 'poll interval' could > > be a nice improvement. > > > > You also have the commands 'poll on' and 'poll off' to temporarily > > disable the polling. > > > > Another improvement, but much more invasive, would be to rewrite the > > target polling to try to be faster, or even to allow commands between > > the polling of two cores. > > I think that today's code preempts the user interaction (GDB included) > > to poll all the cores in one shot, then giving back the control. > > On tens of cores this is not going to scale nicely. > > Thank you for pointing me in the right direction.I'll experiment with > increasing the polling interval.Your suggestions about potential > improvements are also very helpful. > Another possibility, but it really depends on what you want to debug. You could put most of the cores in deferred examine. They should be skipped during the polling, thus improving the performance. And if during the debug session you need to enable some of them you have the arp_examine command I have not verified if OpenOCD smp mode works properly with some of the cores in deferred examine. Regards Antonio >
