From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gustavo Padovan Subject: Re: [RFC 5/5] dma-buf/sync_file: rework fence storage in struct file Date: Fri, 24 Jun 2016 10:23:46 -0300 Message-ID: <20160624132346.GC2503@joana> References: <1466695790-2833-1-git-send-email-gustavo@padovan.org> <1466695790-2833-6-git-send-email-gustavo@padovan.org> <20160623212724.GD1086@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.161.194]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9CF8D6EAAC for ; Fri, 24 Jun 2016 13:23:50 +0000 (UTC) Received: by mail-yw0-f194.google.com with SMTP id v77so14892368ywg.2 for ; Fri, 24 Jun 2016 06:23:50 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20160623212724.GD1086@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Chris Wilson , dri-devel@lists.freedesktop.org, marcheu@google.com, Daniel Stone , seanpaul@google.com, Daniel Vetter , linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com List-Id: dri-devel@lists.freedesktop.org MjAxNi0wNi0yMyBDaHJpcyBXaWxzb24gPGNocmlzQGNocmlzLXdpbHNvbi5jby51az46Cgo+IE9u IFRodSwgSnVuIDIzLCAyMDE2IGF0IDEyOjI5OjUwUE0gLTAzMDAsIEd1c3Rhdm8gUGFkb3ZhbiB3 cm90ZToKPiA+IC1zdGF0aWMgdm9pZCBzeW5jX2ZpbGVfYWRkX3B0KHN0cnVjdCBzeW5jX2ZpbGUg KnN5bmNfZmlsZSwgaW50ICppLAo+ID4gK3N0YXRpYyBpbnQgc3luY19maWxlX3NldF9mZW5jZShz dHJ1Y3Qgc3luY19maWxlICpzeW5jX2ZpbGUsCj4gPiArCQkJICAgICAgIHN0cnVjdCBmZW5jZSAq KmZlbmNlcykKPiA+ICt7Cj4gPiArCXN0cnVjdCBmZW5jZV9hcnJheSAqYXJyYXk7Cj4gPiArCj4g PiArCWlmIChzeW5jX2ZpbGUtPm51bV9mZW5jZXMgPT0gMSkgewo+ID4gKwkJc3luY19maWxlLT5m ZW5jZSA9IGZlbmNlc1swXTsKPiAKPiBTdHJhaWdodGZvcndhcmQgcG9pbnRlciBhc3NpZ25tZW50 Lgo+IAo+ID4gKwl9IGVsc2Ugewo+ID4gKwkJYXJyYXkgPSBmZW5jZV9hcnJheV9jcmVhdGUoc3lu Y19maWxlLT5udW1fZmVuY2VzLCBmZW5jZXMsCj4gPiArCQkJCQkgICBmZW5jZV9jb250ZXh0X2Fs bG9jKDEpLCAxLCBmYWxzZSk7Cj4gPiArCQlpZiAoIWFycmF5KQo+ID4gKwkJCXJldHVybiAtRU5P TUVNOwo+ID4gKwo+ID4gKwkJc3luY19maWxlLT5mZW5jZSA9ICZhcnJheS0+YmFzZTsKPiAKPiBO ZXcgcmVmZXJlbmNlLgo+IAo+IEltYmFsYW5jZSB3aWxsIHByb21wdGx5IGdvIGJhbmcgYWZ0ZXIg d2UgcmVsZWFzZSB0aGUgc2luZ2xlIGZlbmNlWzBdLgo+IAo+IFdvdWxkIGZlbmNlX2FycmF5X2Ny ZWF0ZSgxLCBmZW5jZSkgcmV0dXJuaW5nIGZlbmNlX2dldChmZW5jZSkgYmUgdG9vCj4gbXVjaCBv ZiBhIGhhY2s/Cj4gCj4gSSB3b3VsZCBzdWdnZXN0IGRyb3BwaW5nIHRoZSBleHBvcnRlZCBmZW5j ZV9nZXRfZmVuY2VzKCkgYW5kIHVzZSBhIGxvY2FsCj4gaW5zdGVhZCB0aGF0IGNvdWxkIGF2b2lk IHRoZSBjb3B5LCBlLmcuCj4gCj4gc3RhdGljIHN0cnVjdCBmZW5jZSAqZ2V0X2ZlbmNlcyhzdHJ1 Y3QgZmVuY2UgKipmZW5jZSwKPiAJCQkJdW5zaWduZWQgaW50ICpudW1fZmVuY2VzKQo+IHsKPiAJ aWYgKGZlbmNlX2lzX2FycmF5KCpmZW5jZSkpIHsKPiAJCXN0cnVjdCBmZW5jZV9hcnJheSAqYXJy YXkgPSB0b19mZW5jZV9hcnJheSgqZmVuY2UpOwo+IAkJKm51bV9mZW5jZXMgPSBhcnJheS0+bnVt X2ZlbmNlczsKPiAJCXJldHVybiBhcnJheS0+ZmVuY2VzOwo+IAl9IGVsc2Ugewo+IAkJKm51bV9m ZW5jZXMgPSAxOwo+IAkJcmV0dXJuIGZlbmNlOwo+IAl9Cj4gfQo+IAo+IHN5bmNfZmlsZV9tZXJn ZSgpIHsKPiAJaW50IG51bV9mZW5jZXMsIG51bV9hX2ZlbmNlcywgbnVtX2JfZmVuY2VzOwo+IAlz dHJ1Y3QgZmVuY2UgKipmZW5jZXMsICoqYV9mZW5jZXMsICoqYl9mZW5jZXM7Cj4gCj4gCWFfZmVu Y2VzID0gZ2V0X2ZlbmNlcygmYSwgJm51bV9hX2ZlbmNlcyk7Cj4gCWJfZmVuY2VzID0gZ2V0X2Zl bmNlcygmYiwgJm51bV9iX2ZlbmNlcyk7Cj4gCj4gCW51bV9mZW5jZXMgPSBudW1fYV9mZW5jZXMg KyBudW1fYl9mZW5jZXM7CgoKWWVzLiBUaGF0IGlzIG11Y2ggY2xlYW5lciBzb2x1dGlvbi4gSSBk aWQgdGhpcyBpbml0aWFsbHkgYnV0IHRoZW4gdHJpZWQKdG8gY29tZSB1cCB3aXRoIC5nZXRfZmVu Y2VzKCksIGJ1dCB0aGF0IHdhcyB0aGUgd3Jvbmcgcm9hZC4KCj4gCj4gPiAgc3RhdGljIHZvaWQg c3luY19maWxlX2ZyZWUoc3RydWN0IGtyZWYgKmtyZWYpCj4gPiAgewo+ID4gIAlzdHJ1Y3Qgc3lu Y19maWxlICpzeW5jX2ZpbGUgPSBjb250YWluZXJfb2Yoa3JlZiwgc3RydWN0IHN5bmNfZmlsZSwK PiA+ICAJCQkJCQkgICAgIGtyZWYpOwo+ID4gLQlpbnQgaTsKPiA+IC0KPiA+IC0JZm9yIChpID0g MDsgaSA8IHN5bmNfZmlsZS0+bnVtX2ZlbmNlczsgKytpKSB7Cj4gPiAtCQlmZW5jZV9yZW1vdmVf Y2FsbGJhY2soc3luY19maWxlLT5jYnNbaV0uZmVuY2UsCj4gPiAtCQkJCSAgICAgICZzeW5jX2Zp bGUtPmNic1tpXS5jYik7Cj4gPiAtCQlmZW5jZV9wdXQoc3luY19maWxlLT5jYnNbaV0uZmVuY2Up Owo+ID4gLQl9Cj4gPiAgCj4gPiArCWZlbmNlX3JlbW92ZV9jYWxsYmFjayhzeW5jX2ZpbGUtPmZl bmNlLCAmc3luY19maWxlLT5jYik7Cj4gPiArCWZlbmNlX3RlYXJkb3duKHN5bmNfZmlsZS0+ZmVu Y2UpOwo+IAo+IEhtbS4gQ291bGQgd2UgZGV0ZWN0IHRoZSByZW1vdmFsIG9mIHRoZSBsYXN0IGNh bGxiYWNrIGFuZCBwcm9wYWdhdGUgdGhhdAo+IHRvIHRoZSBmZW5jZV9hcnJheT8gKFJhdGhlciB0 aGVuIGludHJvZHVjZSBhIG1hbnVhbCBjYWxsIHRvCj4gZmVuY2VfdGVhcmRvd24uKQoKTWF5YmUu IEknbGwgbG9vayBpbnRvIHdheXMgdG8gaWRlbnRpZnkgdGhhdC4gV2hhdCBJIGRpZCBkdXJpbmcg dGhlCmRldmVsb3BtZW50IG9mIHRoaXMgcGF0Y2ggd2FzIHRvIGhhdmUgYSBmZW5jZV9hcnJheV9k ZXN0cm95KCksIGJ1dCB0aGVuCkkgbW92ZWQgdG8gLnRlYXJkb3duKCkgaW4gdGhlIGhvcGUgdG8g YWJzdHJhY3QgdGhlIGRpZmYgYmV0d2VlbiBmZW5jZXMKYW5kIGZlbmNlX2FycmF5cy4KCglHdXN0 YXZvCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1k ZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczov L2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751585AbcFXNXv (ORCPT ); Fri, 24 Jun 2016 09:23:51 -0400 Received: from mail-yw0-f194.google.com ([209.85.161.194]:33191 "EHLO mail-yw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751357AbcFXNXu (ORCPT ); Fri, 24 Jun 2016 09:23:50 -0400 Date: Fri, 24 Jun 2016 10:23:46 -0300 From: Gustavo Padovan To: Chris Wilson , dri-devel@lists.freedesktop.org, marcheu@google.com, Daniel Stone , seanpaul@google.com, Daniel Vetter , linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com Subject: Re: [RFC 5/5] dma-buf/sync_file: rework fence storage in struct file Message-ID: <20160624132346.GC2503@joana> Mail-Followup-To: Gustavo Padovan , Chris Wilson , dri-devel@lists.freedesktop.org, marcheu@google.com, Daniel Stone , seanpaul@google.com, Daniel Vetter , linux-kernel@vger.kernel.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com References: <1466695790-2833-1-git-send-email-gustavo@padovan.org> <1466695790-2833-6-git-send-email-gustavo@padovan.org> <20160623212724.GD1086@nuc-i3427.alporthouse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160623212724.GD1086@nuc-i3427.alporthouse.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2016-06-23 Chris Wilson : > On Thu, Jun 23, 2016 at 12:29:50PM -0300, Gustavo Padovan wrote: > > -static void sync_file_add_pt(struct sync_file *sync_file, int *i, > > +static int sync_file_set_fence(struct sync_file *sync_file, > > + struct fence **fences) > > +{ > > + struct fence_array *array; > > + > > + if (sync_file->num_fences == 1) { > > + sync_file->fence = fences[0]; > > Straightforward pointer assignment. > > > + } else { > > + array = fence_array_create(sync_file->num_fences, fences, > > + fence_context_alloc(1), 1, false); > > + if (!array) > > + return -ENOMEM; > > + > > + sync_file->fence = &array->base; > > New reference. > > Imbalance will promptly go bang after we release the single fence[0]. > > Would fence_array_create(1, fence) returning fence_get(fence) be too > much of a hack? > > I would suggest dropping the exported fence_get_fences() and use a local > instead that could avoid the copy, e.g. > > static struct fence *get_fences(struct fence **fence, > unsigned int *num_fences) > { > if (fence_is_array(*fence)) { > struct fence_array *array = to_fence_array(*fence); > *num_fences = array->num_fences; > return array->fences; > } else { > *num_fences = 1; > return fence; > } > } > > sync_file_merge() { > int num_fences, num_a_fences, num_b_fences; > struct fence **fences, **a_fences, **b_fences; > > a_fences = get_fences(&a, &num_a_fences); > b_fences = get_fences(&b, &num_b_fences); > > num_fences = num_a_fences + num_b_fences; Yes. That is much cleaner solution. I did this initially but then tried to come up with .get_fences(), but that was the wrong road. > > > static void sync_file_free(struct kref *kref) > > { > > struct sync_file *sync_file = container_of(kref, struct sync_file, > > kref); > > - int i; > > - > > - for (i = 0; i < sync_file->num_fences; ++i) { > > - fence_remove_callback(sync_file->cbs[i].fence, > > - &sync_file->cbs[i].cb); > > - fence_put(sync_file->cbs[i].fence); > > - } > > > > + fence_remove_callback(sync_file->fence, &sync_file->cb); > > + fence_teardown(sync_file->fence); > > Hmm. Could we detect the removal of the last callback and propagate that > to the fence_array? (Rather then introduce a manual call to > fence_teardown.) Maybe. I'll look into ways to identify that. What I did during the development of this patch was to have a fence_array_destroy(), but then I moved to .teardown() in the hope to abstract the diff between fences and fence_arrays. Gustavo