Paolo Bonzini <pbonz...@redhat.com> writes: >> > The patch series changes things in stages. >> > >> > First we move the break/watchpoints into an array which is more >> > amenable to RCU control that the QLIST. We then control the life time >> > of references to break/watchpoint data by removing long held >> > references in the target code and getting information when needed from >> > the core. Then we stop dynamically allocation the watch/breakpoint >> > data and store it directly in the array which makes iteration across >> > the list a bit more cache friendly than referenced pointers. Finally >> > addition and removal of elements of the array is put under RCU >> > control. This ensures there is always a safe array of data to check >> > in the run-loop. >> >> I a little bit unsure if we really want to complicate things with RCU. >> Why don't we simply protect the lists with a mutex given that there's no >> contention expected? BTW, as it comes to debugging, I suppose we don't >> expect great performance anyway. > > Mutexes do introduce some overhead. The breakpoints list are mostly touched > during translation, but watchpoints aren't so we could use tb_lock for > breakpoints and a separate per-CPU mutex for watchpoints. That could > indeed work.
The watchpoint contention is the biggest one. FWIW I like the RCU approach because it is low impact when running (and I'm hoping faster as well by not being a linked list). It's not a major problem in system mode because generally the system is halted when changes are made to the list. However I'd like to solve it properly for both system and user-mode so I can then forgot about another special case. -- Alex Bennée
