Il 08/10/2013 15:47, Andreas Färber ha scritto: > Am 08.10.2013 10:47, schrieb Paolo Bonzini: >> This series moves the icount state under the same seqlock as the "normal" >> vm_clock implementation. >> >> It is not yet 100% thread-safe, because the CPU list should be moved >> under RCU protection (due to the call to !all_cpu_threads_idle() >> in qemu_clock_warp). However it is a substantial step forward, the >> only uncovered case being CPU hotplug. >> >> Please review. >> >> Paolo >> >> Paolo Bonzini (8): >> timers: extract timer_mod_ns_locked and timerlist_rearm >> timers: add timer_mod_anticipate and timer_mod_anticipate_ns > >> timers: use cpu_get_icount() directly >> timers: reorganize icount_warp_rt >> timers: prepare the code for future races in calling qemu_clock_warp >> timers: introduce cpu_get_clock_locked >> timers: document (future) locking rules for icount >> timers: make icount thread-safe > > These patches touch cpus.c exclusively, so "timers:" is rather misleading.
I can change that to "icount". > As you know I have pending patches (in need of rebase due to the > performance issue you raised) moving the icount CPU fields around. > Is there anything in particular I should be aware of? Looks to me as if > this may be orthogonal? It's entirely orthogonal. It doesn't affect the cpu-exec part of icount, only the "timers" :) part. > What about the previous patch disabling icount for -smp? Does this > series supersede it or does it fix different concurrency issues? This is for making accesses to icount safe without holding the BQL. icount for -smp remains just as broken as before. Paolo
