Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-25 Thread Daniel Vetter
On Thu, Sep 24, 2020 at 05:15:00PM +0100, Qais Yousef wrote: > On 09/24/20 10:49, Daniel Vetter wrote: > > [...] > > > > > I also thought kernel threads can be distinguished from others, so > > > > userspace shouldn't be able to sneak in and get elevated by accident. > > > > > > I guess maybe

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-24 Thread Qais Yousef
On 09/24/20 10:49, Daniel Vetter wrote: [...] > > > I also thought kernel threads can be distinguished from others, so > > > userspace shouldn't be able to sneak in and get elevated by accident. > > > > I guess maybe you could look at the parent? I still would like to > > think that we could

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-24 Thread Rob Clark
On Thu, Sep 24, 2020 at 1:49 AM Daniel Vetter wrote: > > On Wed, Sep 23, 2020 at 07:33:17PM -0700, Rob Clark wrote: > > On Wed, Sep 23, 2020 at 8:25 AM Daniel Vetter wrote: > > > > > > On Tue, Sep 22, 2020 at 07:48:10AM -0700, Rob Clark wrote: > > > > On Mon, Sep 21, 2020 at 11:59 PM Daniel

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-24 Thread Daniel Vetter
On Wed, Sep 23, 2020 at 07:33:17PM -0700, Rob Clark wrote: > On Wed, Sep 23, 2020 at 8:25 AM Daniel Vetter wrote: > > > > On Tue, Sep 22, 2020 at 07:48:10AM -0700, Rob Clark wrote: > > > On Mon, Sep 21, 2020 at 11:59 PM Daniel Vetter wrote: > > > > > > > > On Mon, Sep 21, 2020 at 5:16 PM Rob

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-23 Thread Rob Clark
On Wed, Sep 23, 2020 at 8:25 AM Daniel Vetter wrote: > > On Tue, Sep 22, 2020 at 07:48:10AM -0700, Rob Clark wrote: > > On Mon, Sep 21, 2020 at 11:59 PM Daniel Vetter wrote: > > > > > > On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote: > > > > > > > > On Mon, Sep 21, 2020 at 2:21 AM Daniel

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-23 Thread Daniel Vetter
On Tue, Sep 22, 2020 at 07:48:10AM -0700, Rob Clark wrote: > On Mon, Sep 21, 2020 at 11:59 PM Daniel Vetter wrote: > > > > On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote: > > > > > > On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote: > > > > > > > > On Sat, Sep 19, 2020 at 12:37:23PM -0700,

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-22 Thread Rob Clark
On Mon, Sep 21, 2020 at 11:59 PM Daniel Vetter wrote: > > On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote: > > > > On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote: > > > > > > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote: > > > > From: Rob Clark > > > > > > > > The android

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-22 Thread Daniel Vetter
On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote: > > On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote: > > > > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > The android userspace treats the display pipeline as a realtime problem. > > > And

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-21 Thread Rob Clark
On Mon, Sep 21, 2020 at 9:10 AM Qais Yousef wrote: > > On 09/19/20 12:37, Rob Clark wrote: > > From: Rob Clark > > > > The android userspace treats the display pipeline as a realtime problem. > > And arguably, if your goal is to not miss frame deadlines (ie. vblank), > > it is. (See

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-21 Thread Rob Clark
On Mon, Sep 21, 2020 at 8:16 AM Rob Clark wrote: > > On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote: > > > > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > The android userspace treats the display pipeline as a realtime problem. > > > And

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-21 Thread Qais Yousef
On 09/19/20 12:37, Rob Clark wrote: > From: Rob Clark > > The android userspace treats the display pipeline as a realtime problem. > And arguably, if your goal is to not miss frame deadlines (ie. vblank), > it is. (See https://lwn.net/Articles/809545/ for the best explaination > that I found.)

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-21 Thread Rob Clark
On Mon, Sep 21, 2020 at 8:16 AM Rob Clark wrote: > > On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote: > > > > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > The android userspace treats the display pipeline as a realtime problem. > > > And

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-21 Thread Rob Clark
On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote: > > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote: > > From: Rob Clark > > > > The android userspace treats the display pipeline as a realtime problem. > > And arguably, if your goal is to not miss frame deadlines (ie. vblank), > >

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-21 Thread Tejun Heo
Hello, On Mon, Sep 21, 2020 at 11:21:54AM +0200, Daniel Vetter wrote: > The part I don't like about this is that it all feels rather hacked > together, and if we add more stuff (or there's some different thing in the > system that also needs rt scheduling) then it doesn't compose. > > So

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-21 Thread peterz
On Mon, Sep 21, 2020 at 11:21:54AM +0200, Daniel Vetter wrote: > So question to rt/worker folks: What's the best way to let userspace set > the scheduling mode and priorities of things the kernel does on its > behalf? Surely we're not the first ones where if userspace runs with some > rt priority

Re: [PATCH 0/3] drm: commit_work scheduling

2020-09-21 Thread Daniel Vetter
On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote: > From: Rob Clark > > The android userspace treats the display pipeline as a realtime problem. > And arguably, if your goal is to not miss frame deadlines (ie. vblank), > it is. (See https://lwn.net/Articles/809545/ for the best

[PATCH 0/3] drm: commit_work scheduling

2020-09-19 Thread Rob Clark
From: Rob Clark The android userspace treats the display pipeline as a realtime problem. And arguably, if your goal is to not miss frame deadlines (ie. vblank), it is. (See https://lwn.net/Articles/809545/ for the best explaination that I found.) But this presents a problem with using