From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH v2 6/8] kvm tools: Add rwlock wrapper Date: Mon, 30 May 2011 12:13:33 +0200 Message-ID: <20110530101333.GB17821@elte.hu> References: <1306744247-26051-1-git-send-email-levinsasha928@gmail.com> <1306744247-26051-6-git-send-email-levinsasha928@gmail.com> <20110530084309.GH30513@elte.hu> <1306748069.14564.52.camel@lappy> <1306748796.14564.62.camel@lappy> <20110530095645.GC8461@elte.hu> <1306749934.14564.71.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pekka Enberg , kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com, "Paul E. McKenney" To: Sasha Levin Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:60180 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752105Ab1E3KNo (ORCPT ); Mon, 30 May 2011 06:13:44 -0400 Content-Disposition: inline In-Reply-To: <1306749934.14564.71.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: * Sasha Levin wrote: > On Mon, 2011-05-30 at 11:56 +0200, Ingo Molnar wrote: > > * Sasha Levin wrote: > > > > > I'm just saying that we're limited to as many VCPU threads as we > > > can create. br_read_lock() won't do anything on a non-VCPU thread, > > > which makes it impossible to test it on non-VCPUs. > > > > btw., i wondered about that limit - don't we want to fix it? > > > > I mean, there's no fundamental reason why brlocks should do 'nothing' > > in worker threads. In fact it's a subtle breakage waiting AFAICS. > > Can they do anything useful without locking? I think we should work > on integrating an RCU and changing brlocks to use that instead of > focusing too much on the current implementation. What do you mean 'without locking'? If a worker thread uses a br_read_lock() then that will be 'locking'. It should map to a real read_lock() in the rwlock debug case, etc. > This will also fix that limit you don't like :) I'd prefer brlocks to more complex solutions in cases where the write path is very infrequent! So we don't want to keep brlocks intentionally crippled. Currently we should at minimum need to BUG_ON() if br_read_lock() or br_write_lock() is called in a worker thread context, right? > > We should have enumeration for all threads that kvm starts, and > > that we can use for a generic pause/resume facility. Can you see > > anything that prevents that model? > > Theres a difference between how you would pause a VCPU thread as > opposed to a non-VCPU thread, other than that - no. We could use a > thread manager. Exactly, which would be useful for other purposes as well :-) This only involves the write path so it is not an issue. Thanks, Ingo