From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933869AbdKGM35 (ORCPT ); Tue, 7 Nov 2017 07:29:57 -0500 Received: from mail.kapsi.fi ([91.232.154.25]:48691 "EHLO mail.kapsi.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933843AbdKGM3y (ORCPT ); Tue, 7 Nov 2017 07:29:54 -0500 Subject: Re: [PATCH 08/10] drm/tegra: Implement dynamic channel allocation model To: Dmitry Osipenko , Mikko Perttunen , thierry.reding@gmail.com, jonathanh@nvidia.com References: <20171105110118.15142-1-mperttunen@nvidia.com> <20171105110118.15142-9-mperttunen@nvidia.com> <429d9b2b-8797-adc6-c767-d5bcf735c947@gmail.com> Cc: dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org From: Mikko Perttunen Message-ID: <38fcf947-0d5d-e2c7-f49f-9efce5eeb1a3@kapsi.fi> Date: Tue, 7 Nov 2017 14:29:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <429d9b2b-8797-adc6-c767-d5bcf735c947@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 62.209.167.43 X-SA-Exim-Mail-From: cyndis@kapsi.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > >> For now, this patch only adapts VIC to the new model. >> > > I think VIC's conversion should be a distinct patch. Sure. Cheers, Mikko