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
