Re: [PATCH 4/7] drm/i915/perf: add new open param to configure polling of OA buffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 12 Mar 2020 13:37:12 -0700, Lionel Landwerlin wrote:
> On 12/03/2020 21:27, Dixit, Ashutosh wrote:
> > On Tue, 03 Mar 2020 14:19:02 -0800, Umesh Nerlige Ramappa wrote:
> >> From: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx>
> >>
> >> This new parameter let's the application choose how often the OA
> >> buffer should be checked on the CPU side for data availability. Longer
> >> polling period tend to reduce CPU overhead if the application does not
> >> care about somewhat real time data collection.
> >>
> >> v2: Allow disabling polling completely with 0 value (Lionel)
> >> v3: Version the new parameter (Joonas)
> >> v4: Rebase (Umesh)
> > Hi Lionel, I was thinking that one way to keep things simple for now (and
> > fix the high cpu usage issue) would be to expose _ONLY_ this OA poll period
> > parameter to user space. That is we don't expose the interrupt or the flush
> > ioctl to user space at this time. This way the user will be able to
> > configure the hrtimer frequency to a lower value to bring down the cpu
> > usage.
> >
> > Also we would disallow disabling the timer (and internally also not use the
> > interrupt). So everything will happen in exactly the same way as it used to
> > (no other changes needed) but at a lower rate if the user so chooses.
> >
> > What do you think about this?
> >
> > Thanks!
> > --
> > Ashutosh
>
> Sure, just make sure the users know about this.

Ok, so the plan now is to just post and review/merge the first 4 patches
mostly as is, except that the poll timer cannot be disabled. IMO this
should solve the cpu usage issue. Then we can take up the remaining 3
interrupt and flush patches and see if they are really needed and move them
forward if they are.

> The fact that they can now select timer values that will potentially lead
> to the loss of the buffer's data because it was overridden.

I think you mean over-written. You are right but I think there is way
around this and we can post that patch soon which I think will avoid this
issue too.

Thanks!
--
Ashutosh
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux