All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Mikko Perttunen <cyndis-/1wQRMveznE@public.gmane.org>,
	Mikko Perttunen
	<mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 08/10] drm/tegra: Implement dynamic channel allocation model
Date: Mon, 13 Nov 2017 14:49:00 +0300	[thread overview]
Message-ID: <ce92a134-a18f-1337-f7f6-031f46ce6fcd@gmail.com> (raw)
In-Reply-To: <38fcf947-0d5d-e2c7-f49f-9efce5eeb1a3-/1wQRMveznE@public.gmane.org>

On 07.11.2017 15:29, Mikko Perttunen wrote:
> On 05.11.2017 19:43, Dmitry Osipenko wrote:
>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>> In the traditional channel allocation model, a single hardware channel
>>> was allocated for each client. This is simple from an implementation
>>> perspective but prevents use of hardware scheduling.
>>>
>>> This patch implements a channel allocation model where when a user
>>> submits a job for a context, a hardware channel is allocated for
>>> that context. The same channel is kept for as long as there are
>>> incomplete jobs for that context. This way we can use hardware
>>> scheduling and channel isolation between userspace processes, but
>>> also prevent idling contexts from taking up hardware resources.
>>>
>>
>> The dynamic channels resources (pushbuf) allocation is very expensive,
>> neglecting all benefits that this model should bring at least in non-IOMMU case.
>> We could have statically preallocated channels resources or defer resources
>> freeing.
> 
> This is true. I'll try to figure out a nice way to keep the pushbuf allocations.

One variant could be to have all channels resources statically preallocated in a
non-IOMMU case because CMA is expensive. Then you should measure the allocations
impact in a case of IOMMU allocations and if it is significant, maybe implement
Host1x PM autosuspend, releasing all channels when Host1x become idle.

I think the above should be efficient and easy to implement.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Mikko Perttunen <cyndis@kapsi.fi>,
	Mikko Perttunen <mperttunen@nvidia.com>,
	thierry.reding@gmail.com, jonathanh@nvidia.com
Cc: dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 08/10] drm/tegra: Implement dynamic channel allocation model
Date: Mon, 13 Nov 2017 14:49:00 +0300	[thread overview]
Message-ID: <ce92a134-a18f-1337-f7f6-031f46ce6fcd@gmail.com> (raw)
In-Reply-To: <38fcf947-0d5d-e2c7-f49f-9efce5eeb1a3@kapsi.fi>

On 07.11.2017 15:29, Mikko Perttunen wrote:
> On 05.11.2017 19:43, Dmitry Osipenko wrote:
>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>> In the traditional channel allocation model, a single hardware channel
>>> was allocated for each client. This is simple from an implementation
>>> perspective but prevents use of hardware scheduling.
>>>
>>> This patch implements a channel allocation model where when a user
>>> submits a job for a context, a hardware channel is allocated for
>>> that context. The same channel is kept for as long as there are
>>> incomplete jobs for that context. This way we can use hardware
>>> scheduling and channel isolation between userspace processes, but
>>> also prevent idling contexts from taking up hardware resources.
>>>
>>
>> The dynamic channels resources (pushbuf) allocation is very expensive,
>> neglecting all benefits that this model should bring at least in non-IOMMU case.
>> We could have statically preallocated channels resources or defer resources
>> freeing.
> 
> This is true. I'll try to figure out a nice way to keep the pushbuf allocations.

One variant could be to have all channels resources statically preallocated in a
non-IOMMU case because CMA is expensive. Then you should measure the allocations
impact in a case of IOMMU allocations and if it is significant, maybe implement
Host1x PM autosuspend, releasing all channels when Host1x become idle.

I think the above should be efficient and easy to implement.

  parent reply	other threads:[~2017-11-13 11:49 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-05 11:01 [PATCH 00/10] Dynamic Host1x channel allocation Mikko Perttunen
2017-11-05 11:01 ` [PATCH 02/10] gpu: host1x: Print MLOCK state in debug dumps on T186 Mikko Perttunen
2017-11-05 11:01 ` [PATCH 03/10] gpu: host1x: Add lock around channel allocation Mikko Perttunen
2017-11-05 11:01 ` [PATCH 04/10] gpu: host1x: Lock classes during job submission Mikko Perttunen
2017-11-05 11:01   ` Mikko Perttunen
     [not found]   ` <20171105110118.15142-5-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2017-11-05 16:46     ` Dmitry Osipenko
2017-11-05 16:46       ` Dmitry Osipenko
2017-11-07 12:28       ` Mikko Perttunen
     [not found]         ` <ef08d3d8-94a7-8804-c339-5310719333f3-/1wQRMveznE@public.gmane.org>
2017-11-07 21:23           ` Dmitry Osipenko
2017-11-07 21:23             ` Dmitry Osipenko
     [not found]             ` <dc39398b-ea49-6e97-28ba-652f8b49db44-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-12-05 13:21               ` Mikko Perttunen
2017-12-05 13:21                 ` Mikko Perttunen
     [not found]                 ` <2b4d9283-dabe-9e1f-f8cb-6ddbc16e3f0f-/1wQRMveznE@public.gmane.org>
2017-12-05 13:43                   ` Dmitry Osipenko
2017-12-05 13:43                     ` Dmitry Osipenko
2017-11-05 11:01 ` [PATCH 05/10] gpu: host1x: Add job done callback Mikko Perttunen
     [not found] ` <20171105110118.15142-1-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2017-11-05 11:01   ` [PATCH 01/10] gpu: host1x: Parameterize channel aperture size Mikko Perttunen
2017-11-05 11:01     ` Mikko Perttunen
2017-11-05 11:01   ` [PATCH 06/10] drm/tegra: Deliver job completion callback to client Mikko Perttunen
2017-11-05 11:01     ` Mikko Perttunen
     [not found]     ` <20171105110118.15142-7-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2017-11-16 16:33       ` Dmitry Osipenko
2017-11-16 16:33         ` Dmitry Osipenko
2017-11-16 16:40     ` Dmitry Osipenko
     [not found]       ` <1afa1ba9-3103-3672-2e15-fb8c7de2520b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-29  9:09         ` Mikko Perttunen
2017-11-29  9:09           ` Mikko Perttunen
2017-11-05 11:01   ` [PATCH 07/10] drm/tegra: Make syncpoints be per-context Mikko Perttunen
2017-11-05 11:01     ` Mikko Perttunen
2017-11-07 15:34   ` [PATCH 00/10] Dynamic Host1x channel allocation Dmitry Osipenko
2017-11-07 15:34     ` Dmitry Osipenko
2017-11-05 11:01 ` [PATCH 08/10] drm/tegra: Implement dynamic channel allocation model Mikko Perttunen
     [not found]   ` <20171105110118.15142-9-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2017-11-05 17:43     ` Dmitry Osipenko
2017-11-05 17:43       ` Dmitry Osipenko
2017-11-07 12:29       ` Mikko Perttunen
     [not found]         ` <38fcf947-0d5d-e2c7-f49f-9efce5eeb1a3-/1wQRMveznE@public.gmane.org>
2017-11-13 11:49           ` Dmitry Osipenko [this message]
2017-11-13 11:49             ` Dmitry Osipenko
2017-11-05 11:01 ` [PATCH 09/10] drm/tegra: Boot VIC in runtime resume Mikko Perttunen
2017-11-05 11:01 ` [PATCH 10/10] gpu: host1x: Optionally block when acquiring channel Mikko Perttunen
2017-11-05 11:01   ` Mikko Perttunen
     [not found]   ` <20171105110118.15142-11-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2017-11-05 17:14     ` Dmitry Osipenko
2017-11-05 17:14       ` Dmitry Osipenko
     [not found]       ` <9c5676eb-ba6f-c187-29e4-7b331bd3962f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-07 13:11         ` Mikko Perttunen
2017-11-07 13:11           ` Mikko Perttunen
2017-11-07 15:29           ` Dmitry Osipenko
     [not found]             ` <1b35ec93-167b-3436-0ff2-5e2e0886aea7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-10 21:15               ` Dmitry Osipenko
2017-11-10 21:15                 ` Dmitry Osipenko
     [not found]                 ` <dcb8c4ef-9eb9-556f-cc96-651a50636afa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-12 11:23                   ` Dmitry Osipenko
2017-11-12 11:23                     ` Dmitry Osipenko
2017-11-29  9:10                     ` Mikko Perttunen
2017-11-29 12:18                       ` Dmitry Osipenko
     [not found]                         ` <07e28b40-dd2b-774f-2d07-3b5d6cf08c46-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-29 12:25                           ` Mikko Perttunen
2017-11-29 12:25                             ` Mikko Perttunen
     [not found]                             ` <a4adb6ac-b72e-3f9b-fc6c-2a56bc6537ce-/1wQRMveznE@public.gmane.org>
2017-11-29 12:37                               ` Dmitry Osipenko
2017-11-29 12:37                                 ` Dmitry Osipenko

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=ce92a134-a18f-1337-f7f6-031f46ce6fcd@gmail.com \
    --to=digetx-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=cyndis-/1wQRMveznE@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=thierry.reding-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.