From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF22v-00034w-6O for qemu-devel@nongnu.org; Mon, 20 Jun 2016 12:27:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF22p-0004em-1j for qemu-devel@nongnu.org; Mon, 20 Jun 2016 12:27:31 -0400 Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:35963) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF22o-0004ea-DS for qemu-devel@nongnu.org; Mon, 20 Jun 2016 12:27:26 -0400 Received: by mail-wm0-x231.google.com with SMTP id f126so76366011wma.1 for ; Mon, 20 Jun 2016 09:27:26 -0700 (PDT) From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <702806117.314024.1466438917254.JavaMail.zimbra@redhat.com> Date: Mon, 20 Jun 2016 17:27:24 +0100 Message-ID: <8737o7su4z.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC 0/7] Safe watch and breakpoint manipulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Sergey Fedorov , mttcg@greensocs.com, qemu-devel@nongnu.org, fred konrad , a rigo , cota@braap.org, bobby prani , mark burton , jan kiszka , rth@twiddle.net, peter maydell , claudio fontana Paolo Bonzini 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