All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>
To: christian.koenig-5C7GfCeVMHo@public.gmane.org,
	"Marek Olšák" <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: amd-gfx mailing list
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport
Date: Tue, 17 Jul 2018 09:26:24 +0200	[thread overview]
Message-ID: <126a68a9-43f4-c747-89d1-114dc29ea4e9@daenzer.net> (raw)
In-Reply-To: <5374dffa-45c9-1bd6-79b9-cc4450a96aeb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On 2018-07-17 08:50 AM, Christian König wrote:
> Am 16.07.2018 um 18:05 schrieb Michel Dänzer:
>> On 2018-07-13 08:47 PM, Marek Olšák wrote:
>>> On Fri, Jul 13, 2018 at 4:28 AM, Michel Dänzer <michel@daenzer.net>
>>> wrote:
>>>> On 2018-07-12 07:03 PM, Marek Olšák wrote:
>>>>> On Thu, Jul 12, 2018, 3:31 AM Michel Dänzer <michel@daenzer.net>
>>>>> wrote:
>>>>>> What is the rationale for this? I.e. why do you want to not store
>>>>>> some
>>>>>> handles in the hash table?
>>>>>
>>>>> Because I have the option.
>>>> Seems like you're expecting this patch to be accepted without providing
>>>> any real justification for it (here or in the corresponding Mesa
>>>> patch).
>>>> NAK from me if so.
>>> The real justification is implied by the patch. See:
>>> amdgpu_add_handle_to_table
>>> Like I said: There is no risk of regression and it simplifies one
>>> simple case trivially. We shouldn't have to even talk about it.
>> IMO you haven't provided enough justification for adding API which is
>> prone to breakage if used incorrectly.
>>
>> Other opinions?
> 
> I understand the reason why Marek wants to do this, but I agree that
> this is a little bit dangerous if used incorrectly.
> 
> On the other hand I don't see any other way to sanely handle it either.

Sanely handle what exactly? :) I still haven't seen any description of
an actual problem, other than "the handle is stored in the hash table".


>>>> I'd rather add the handle to the hash table in amdgpu_bo_alloc,
>>>> amdgpu_create_bo_from_user_mem and amdgpu_bo_import instead of in
>>>> amdgpu_bo_export, making amdgpu_bo_export(bo,
>>>> amdgpu_bo_handle_type_kms,
>>>> ...) essentially free. In the unlikely (since allocating a BO from the
>>>> kernel is expensive) case that the hash table shows up on profiles, we
>>>> can optimize it.
>>> The hash table isn't very good for high BO counts. The time complexity
>>> of a lookup is O(n).
>> A lookup is only needed in amdgpu_bo_import. amdgpu_bo_alloc and
>> amdgpu_create_bo_from_user_mem can just add the handle to the hash
>> bucket directly.
>>
>> Do you know of, or can you imagine, any workload where amdgpu_bo_import
>> is called often enough for this to be a concern?
> 
> MM interop with GFX usually imports BOs on each frame, so that can hurt
> here.

That's always the same set of BOs in the steady state, right? So it's
easy to make the repeated lookups fast, by moving them to the start of
their hash buckets.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2018-07-17  7:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-12  0:47 [PATCH libdrm] amdgpu: add amdgpu_bo_handle_type_kms_noimport Marek Olšák
     [not found] ` <20180712004750.2024-1-maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-12  1:14   ` Zhang, Jerry (Junwei)
     [not found]     ` <5B46AB60.1000808-5C7GfCeVMHo@public.gmane.org>
2018-07-12  1:29       ` Marek Olšák
2018-07-12  1:39       ` Zhang, Jerry (Junwei)
2018-07-12  2:09   ` zhoucm1
     [not found]     ` <ccb1d49f-ab4f-f561-f328-809ea34edcb0-5C7GfCeVMHo@public.gmane.org>
2018-07-12  2:41       ` Marek Olšák
2018-07-12  7:31   ` Michel Dänzer
     [not found]     ` <9a8d8f7f-a468-fd5b-dec5-472ce9c88483-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-12 17:03       ` Marek Olšák
     [not found]         ` <CAAxE2A6Vz08sWXiaB6B-F4_P7Fy6uDuJ7aF2gHLXZ4N3zj9sXw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-13  8:28           ` Michel Dänzer
     [not found]             ` <a291b3b5-25bc-385a-5242-9bd75ec423e9-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-13 18:47               ` Marek Olšák
     [not found]                 ` <CAAxE2A7ffmO=Tv_DSWhPciF+y5q_wbaBYgcqHvxQVkeVfhBhdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-16 16:05                   ` Michel Dänzer
     [not found]                     ` <31980a46-1d16-8ead-cc2b-5a5b9eb4d530-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-16 18:51                       ` Marek Olšák
     [not found]                         ` <CAAxE2A5SUypT+huhKKdSAWXZ8x+wgPSy2FGqLRTj_io+L1qLqA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-17  8:57                           ` Michel Dänzer
     [not found]                             ` <97d0f539-1a98-f9fc-1ed5-5de7c5a8c3d0-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-17 18:14                               ` Marek Olšák
     [not found]                                 ` <CAAxE2A5ij49A-62_wqD6923nn1w6gT6iY-jeC2HUP3ksYacZQQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-18 15:55                                   ` Michel Dänzer
     [not found]                                     ` <b2335e6f-0553-a3a8-0157-f4dc99ac9cea-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-20  3:48                                       ` Marek Olšák
2018-07-17  6:50                       ` Christian König
     [not found]                         ` <5374dffa-45c9-1bd6-79b9-cc4450a96aeb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-17  7:26                           ` Michel Dänzer [this message]
     [not found]                             ` <126a68a9-43f4-c747-89d1-114dc29ea4e9-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-17  7:33                               ` Christian König
     [not found]                                 ` <3cc456c1-929d-4aee-2e8b-7d4edb023382-5C7GfCeVMHo@public.gmane.org>
2018-07-17  7:46                                   ` Michel Dänzer
     [not found]                                     ` <0f28de35-1928-2af3-8b8d-13c61b25e285-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-17  7:59                                       ` Christian König
     [not found]                                         ` <45bab640-d574-b822-e5c8-69fe67626a9a-5C7GfCeVMHo@public.gmane.org>
2018-07-17  8:03                                           ` Michel Dänzer
     [not found]                                             ` <988daf71-51ef-65e7-48ed-9dc2f3acb3a1-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-17  8:19                                               ` Christian König
     [not found]                                                 ` <a5be38fa-4da6-642f-b297-21261820a908-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-17  8:30                                                   ` Michel Dänzer
     [not found]                                                     ` <9a3c0fb3-c6a8-d59f-89cf-ec32ff6ed630-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-07-17  8:35                                                       ` Christian König
2018-07-24 18:11   ` Marek Olšák
     [not found]     ` <CAAxE2A54HMsqwyGhTn_0kt483qKd5G5UFuZD1-X+JWDZYn-5fg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-25  8:30       ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=126a68a9-43f4-c747-89d1-114dc29ea4e9@daenzer.net \
    --to=michel-otuistvhuppr7s880joybq@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
    --cc=maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.