From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>,
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 6/7] drm/i915/perf: add interrupt enabling parameter
Date: Wed, 4 Mar 2020 10:55:47 +0200 [thread overview]
Message-ID: <729a2c85-3ba6-43c9-b75d-19856c270893@intel.com> (raw)
In-Reply-To: <87wo80u0vn.wl-ashutosh.dixit@intel.com>
On 04/03/2020 07:47, Dixit, Ashutosh wrote:
> On Tue, 03 Mar 2020 14:19:04 -0800, Umesh Nerlige Ramappa wrote:
>> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>
>> This let's the application choose to be driven by the interrupt
>> mechanism of the HW. In conjuction with long periods for checks for
>> the availability of data on the CPU, this can reduce the CPU load when
>> doing capture of OA data.
>>
>> v2: Version the new parameter (Joonas)
>> v3: Rebase (Umesh)
>>
>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
> [snip]
>
>> + /**
>> + * Specifying this property sets up the interrupt mechanism for the OA
>> + * buffer in i915. This option in conjuction with a long polling delay
>> + * for avaibility of OA data can reduce CPU load significantly if you
>> + * do not care about OA data being read as soon as it's available.
>> + *
>> + * This property is available in perf revision 5.
>> + */
>> + DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT,
> What if we do not expose this parameter in the uapi at all and internally
> decide in i915 whether to leave the interrupt either always enabled or
> always disabled (and in that case always use the hrtimer)? This way we
> retain flexibility in i915 if hardware evolves in the future e.g. to use
> watermarks for the interrupt, without yielding control to userspace.
>
> Overall I feel we should avoid exposing unnecessary details of the internal
> implemenation to userspace, they would be neither interested in knowing
> internal details nor know how to properly use these parameters. Shouldn't
> the driver be able to make these kinds of decisions internally?
>
> At this point the only parameter which implicitly exposed to userspace is
> the hrtimer poll period, so perhaps all we need to do is to expose that in
> the uapi? Thoughts?
I guess I agree with you. I can't remember why I exposed it to userspace.
There might be one test that checks the stream reports LOST_BUFFER with
no poll() wakeup, but I guess we could update it.
-Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-03-04 8:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 22:18 [Intel-gfx] [PATCH 0/7] drm/i915/perf: add OA interrupt support Umesh Nerlige Ramappa
2020-03-03 22:18 ` [Intel-gfx] [PATCH 1/7] drm/i915/perf: rework aging tail workaround Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 2/7] drm/i915/perf: move pollin setup to non hw specific code Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 3/7] drm/i915/perf: only append status when data is available Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 4/7] drm/i915/perf: add new open param to configure polling of OA buffer Umesh Nerlige Ramappa
2020-03-12 19:27 ` Dixit, Ashutosh
2020-03-12 20:37 ` Lionel Landwerlin
2020-03-12 22:20 ` Dixit, Ashutosh
2020-03-12 23:10 ` Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 6/7] drm/i915/perf: add interrupt enabling parameter Umesh Nerlige Ramappa
2020-03-04 5:47 ` Dixit, Ashutosh
2020-03-04 8:55 ` Lionel Landwerlin [this message]
2020-03-10 20:08 ` Umesh Nerlige Ramappa
2020-03-10 20:57 ` Lionel Landwerlin
2020-03-03 22:19 ` [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl Umesh Nerlige Ramappa
2020-03-04 5:48 ` Dixit, Ashutosh
2020-03-04 8:52 ` Lionel Landwerlin
2020-03-05 5:56 ` Dixit, Ashutosh
2020-03-09 19:51 ` Umesh Nerlige Ramappa
2020-03-10 20:44 ` Lionel Landwerlin
2020-03-11 3:05 ` Dixit, Ashutosh
2020-03-09 21:15 ` Umesh Nerlige Ramappa
2020-03-04 2:53 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: add OA interrupt support (rev5) Patchwork
2020-03-04 2:58 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-03-04 3:13 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2020-03-04 3:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-04 19:31 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=729a2c85-3ba6-43c9-b75d-19856c270893@intel.com \
--to=lionel.g.landwerlin@intel.com \
--cc=ashutosh.dixit@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=umesh.nerlige.ramappa@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).