From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups v3 Date: Tue, 20 Nov 2012 07:44:34 +0100 Message-ID: <50AB26D2.5090602@vmware.com> References: <1352201511-6383-1-git-send-email-thellstrom@vmware.com> <1352201511-6383-4-git-send-email-thellstrom@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Dave Airlie Cc: airlied@redhat.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org On 11/20/2012 07:19 AM, Dave Airlie wrote: > On Tue, Nov 6, 2012 at 9:31 PM, Thomas Hellstrom wrote: >> The mostly used lookup+get put+potential_destroy path of TTM objects >> is converted to use RCU locks. This will substantially decrease the amount >> of locked bus cycles during normal operation. >> Since we use kfree_rcu to free the objects, no rcu synchronization is needed >> at module unload time. > As this is the first use of RCU in a drm driver from what I can see, > let me remind that the > RCU patent agreement AFAIK only covers GPL works. > > So non-GPL or other OSes porting this code should take not of this. > > Dave. From VMware's side this won't be a problem, since other VMware kernel modules (VMCI IIRC) use RCU. In any case I have a new version of the "vmwgfx optimization" patch series that mostly add documentation and annotation (by using a drm_ht_xxx_rcu) interface for hashtab, after an internal review by Dmitry Torkov. I see you've already applied the original patch series. Do you want me to send out the new one or rebase it against current drm-next? Thanks, Thomas