From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 13/15] cifs: convert cifsFileInfo->count to non-atomic counter Date: Thu, 7 Oct 2010 14:05:44 -0400 Message-ID: <20101007180544.GA18764@lst.de> References: <1286394857-32541-1-git-send-email-jlayton@redhat.com> <1286394857-32541-14-git-send-email-jlayton@redhat.com> <4CAD8972.9090406@suse.de> <20101007071819.2446312b@barsoom.rdu.redhat.com> <4CADB949.2070205@suse.de> <20101007084334.0e03f586@barsoom.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeff Layton , Suresh Jayaraman , linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Steve French Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On Thu, Oct 07, 2010 at 10:37:54AM -0500, Steve French wrote: > > I doubt that a spinlock vs. a rwlock makes much difference, > but a rwlock lock for list insertion/removal seems more intuitive > and overloading it to also protect a counter adds complexity. > Seems more natural to leave it as an atomic counter. The rwlock here is rather non-sensical. A shared/exclusie lock only makes sense if the critical section is large enough to actually benefit from concurrency. With a short critical section like here you still pay the same price in terms of cache line effects, and operations on rwlocks actually are more expensive than on a normal spinlock. We don't actually hae a lot of places where the plain rwlock makes any sense at all - if there's enough reason for concurreny you're better off doing RCU locking anyway.