From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: [PATCH 4/6] kvm tools: Add rwlock wrapper Date: Fri, 27 May 2011 10:11:25 -0400 Message-ID: <20110527141125.GC30292@Krystal> References: <1306419950-19064-4-git-send-email-levinsasha928@gmail.com> <1306426743.3065.34.camel@lappy> <20110526180518.GA3572@elte.hu> <4DDE97CE.4000302@redhat.com> <20110526202531.GA2765@elte.hu> <20110526230508.GA15983@Krystal> <20110527102533.GA24608@elte.hu> <20110527110729.GA26920@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pekka Enberg , Avi Kivity , Sasha Levin , john@jfloren.net, kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com, "Paul E. McKenney" To: Ingo Molnar Return-path: Received: from mail.openrapids.net ([64.15.138.104]:60247 "EHLO blackscsi.openrapids.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751152Ab1E0OL1 (ORCPT ); Fri, 27 May 2011 10:11:27 -0400 Content-Disposition: inline In-Reply-To: <20110527110729.GA26920@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: * Ingo Molnar (mingo@elte.hu) wrote: > > * Ingo Molnar wrote: > > > > This code is very much tied with the kernel scheduler. [...] > > > > It would not be particularly complex to enable user-space to > > request a callback on context switch events. > > > > I was thinking on and off about allowing perf events to generate a > > per sampling event notification signal on specific events, such as > > page faults or context switches. > > I was thinking about that on and off so loudly that Peter implemented > it long ago via fasync support on the perf event fd! :-) > > So if you set a notification signal via fcntl(F_SETOWN) on the > scheduler context switch event fd, the user-space RCU code will get a > signal on every context switch. > > I have not tried it for this purpose yet, so let us know if there are > unexpected complications :) I'm worried about the following complications: Let's define per-process, per-cpu data structures, mapped in userland, that keep track of the per-cpu read-side C.S. nesting count. Let say we use this signal-based mechanism to inform userland of migrations. 1) The first thing I notice is that we're not informed of threads being blocked. So multiple threads taking read-side C.S. in turn on the same CPU as they are being scheduled will corrupt each other's read-side C.S. counter. 2) The second thing I notice is that there is no form of synchronization between the userland execution and delivery of this signal, which leads to interesting race conditions. Any thoughts on how to address these ? Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com