From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 065D7C4727E for ; Wed, 7 Oct 2020 16:44:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9509721582 for ; Wed, 7 Oct 2020 16:44:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qIM+Yh3y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727894AbgJGQoX (ORCPT ); Wed, 7 Oct 2020 12:44:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726105AbgJGQoX (ORCPT ); Wed, 7 Oct 2020 12:44:23 -0400 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18737C061755; Wed, 7 Oct 2020 09:44:23 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id g12so2966342wrp.10; Wed, 07 Oct 2020 09:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1mE5Gwn7xDIbM4htDyTfJFvStSh1Kg9XYcxXUrf4KUg=; b=qIM+Yh3y1tTEMLEhGgZdsvlJJLqbxVhsnJEIVoxm1EkKMcNXPsUH55jARR3ezgWKDx 9DBnk7oaNMu1GJOG7a7oTNnS9Hu4/W0MpHuo8a5rgSgM5MeIEPUrmXEpy4hy3Vu4aT4j QkWouP/erWGYyvTE5hHKbdxlGcsla3Ne/q2GCp5u7MQ8DQWFn4PxZDxffFXIWaFc+ECE dy8nO2lF/XFRfNJoDknZW5CKKKGvBwwf8bsgVftP/ALcXwfGWj3CG6hS8RMrcpbDkMIJ dcj/vTtBzXmFC+52hmFHX4tS76Zum9doFKeHuICoAifeljMVT5FNF7iEnFHU5UJS+dI1 aIxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1mE5Gwn7xDIbM4htDyTfJFvStSh1Kg9XYcxXUrf4KUg=; b=ExxZafcEvIKhc3lkCcTr8vTi2Bi8O2Sznlz9YINhyYYpoiFPkZH4EtL/jEe2yFTnsJ kg2r9QAhJikmYEogUOJSilIl48P219/4j+3DQgswYZaeRWh9JwIQLNVL3McirAoud08z jp4KBwyWMufNtYd9jHm1c/4lzunuze29hvfXeQZZaVqtHnst2l/ynbeO/0+To1K7/5AP P4EF3gYjgXhYbwdt5VO1pSoltxQAWsdjcXmHYfvhLiiPbsZEzIFcItORoWVV4VuDQv8j +lo/kDjppGj4SDy06jge80SRL92x4lPKGtkMMf8Xcbi42WiATOzRaCmqpg0kngJa3qNf tVBQ== X-Gm-Message-State: AOAM530seaS3Afv9tJqBnhB2ywv9+X5EDRq47WWKAX9NUwPnlXQw+wl9 OEn7CsnXro0vs88ztYVeUqbFrQHeVpuWinAJiP0= X-Google-Smtp-Source: ABdhPJz5HXnIE07xhxeYYE0PvUFLfABD/NJndXH7Tzk3cKxWEGnk9LZL0h8rgo1bVNUoAUGvaOwZEIX4OPrvF4gLutw= X-Received: by 2002:adf:bc0f:: with SMTP id s15mr4568520wrg.83.1602089061296; Wed, 07 Oct 2020 09:44:21 -0700 (PDT) MIME-Version: 1.0 References: <20200930211723.3028059-1-robdclark@gmail.com> <20201002105256.GA6112@intel.com> <20201002110544.GB6112@intel.com> <20201005121524.GI6112@intel.com> In-Reply-To: <20201005121524.GI6112@intel.com> From: Rob Clark Date: Wed, 7 Oct 2020 09:44:09 -0700 Message-ID: Subject: Re: [PATCH v2 0/3] drm: commit_work scheduling To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= Cc: Daniel Vetter , Rob Clark , linux-arm-msm , open list , Tim Murray , dri-devel , Tejun Heo , Qais Yousef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 5, 2020 at 5:15 AM Ville Syrj=C3=A4l=C3=A4 wrote: > > On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote: > > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrj=C3=A4l=C3=A4 > > wrote: > > > > > > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrj=C3=A4l=C3=A4 wro= te: > > > > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote: > > > > > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wr= ote: > > > > > > > > > > > > I'm leaning towards converting the other drivers over to use th= e > > > > > > per-crtc kwork, and then dropping the 'commit_work` from atomic= state. > > > > > > I can add a patch to that, but figured I could postpone that ch= urn > > > > > > until there is some by-in on this whole idea. > > > > > > > > > > i915 has its own commit code, it's not even using the current com= mit > > > > > helpers (nor the commit_work). Not sure how much other fun there = is. > > > > > > > > I don't think we want per-crtc threads for this in i915. Seems > > > > to me easier to guarantee atomicity across multiple crtcs if > > > > we just commit them from the same thread. > > > > > > Oh, and we may have to commit things in a very specific order > > > to guarantee the hw doesn't fall over, so yeah definitely per-crtc > > > thread is a no go. > > > > If I'm understanding the i915 code, this is only the case for modeset > > commits? I suppose we could achieve the same result by just deciding > > to pick the kthread of the first CRTC for modeset commits. I'm not > > really so much concerned about parallelism for modeset. > > I'm not entirely happy about the random differences between modesets > and other commits. Ideally we wouldn't need any. > > Anyways, even if we ignore modesets we still have the issue with > atomicity guarantees across multiple crtcs. So I think we still > don't want per-crtc threads, rather it should be thread for each > commit. I don't really see any other way to solve the priority inversion other than per-CRTC kthreads. I've been thinking about it a bit more, and my conclusion is: (1) There isn't really any use for the N+1'th commit to start running before the kthread_work for the N'th commit completes, so I don't mind losing the unbound aspect of the workqueue approach (2) For cases where there does need to be serialization between commits on different CRTCs, since there is a per-CRTC kthread, you could achieve this with locking Since i915 isn't using the atomic helpers here, I suppose it is an option for i915 to just continue doing what it is doing. And I could ofc just stop using the atomic commit helper and do the kthreads thing in msm. But my first preference would be that the commit helper does generally the right thing. BR, -R