From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: [PATCH v3 3/4] drm/ttm: convert to unified vma offset manager
Date: Fri, 19 Jul 2013 11:13:20 +0200
Message-ID: <51E90330.5070702@vmware.com>
References: <1374084860-29768-1-git-send-email-dh.herrmann@gmail.com>
	<1374084860-29768-4-git-send-email-dh.herrmann@gmail.com>
	<51E7AD18.4050100@vmware.com>
	<CANq1E4Q16MKWNBmT5y-OqHbQRNaDPe-EOR4Hm9AbZ2m_ewc-Gg@mail.gmail.com>
	<51E7D080.3030405@vmware.com>
	<CANq1E4SNzPqp-g7Ryo+n+GwpcJHZaLQVTc3AvHEXCvhuz8465w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org>
Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com
	[208.91.2.13])
	by gabe.freedesktop.org (Postfix) with ESMTP id 43363E6887
	for <dri-devel@lists.freedesktop.org>;
	Fri, 19 Jul 2013 02:13:27 -0700 (PDT)
In-Reply-To: <CANq1E4SNzPqp-g7Ryo+n+GwpcJHZaLQVTc3AvHEXCvhuz8465w@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Martin Peres <martin.peres@labri.fr>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, Alex Deucher <alexander.deucher@amd.com>, Ben Skeggs <bskeggs@redhat.com>, Dave Airlie <airlied@redhat.com>
List-Id: dri-devel@lists.freedesktop.org

On 07/18/2013 10:54 PM, David Herrmann wrote:
> Hi
>
> On Thu, Jul 18, 2013 at 1:24 PM, Thomas Hellstrom <thellstrom@vmware.com> wrote:

...

>>
>> I think that if there are good reasons to keep locking internal, I'm fine
>> with that, (And also, of course, with
>> Daniel's proposal). Currently the add / remove / lookup paths are mostly
>> used by TTM during object creation and
>> destruction.
>>
>> However, if the lookup path is ever used by pread / pwrite, that situation
>> might change and we would then like to
>> minimize the locking.
> I tried to keep the change as minimal as I could. Follow-up patches
> are welcome. I just thought pushing the lock into drm_vma_* would
> simplify things. If there are benchmarks that prove me wrong, I'll
> gladly spend some time optimizing that.

In the general case, one reason for designing the locking outside of a 
utilities like this, is that different callers may have
different requirements. For example, the call path is known not to be 
multithreaded at all, or
the caller may prefer a mutex over a spinlock for various reasons. It 
might also be that some callers will want to use
RCU locking in the future if the lookup path becomes busy, and that 
would require *all* users to adapt to RCU object destruction...

I haven't looked at the code closely enough to say that any of this 
applies in this particular case, though.


Thanks,
Thomas


> Thanks
> David