From 26ebd9c734d5b807055c333b29504b05fe971185 Mon Sep 17 00:00:00 2001 From: Robert Bragg Date: Thu, 11 May 2017 16:43:25 +0100 Subject: [PATCH] drm/i915/perf: avoid poll, read, EAGAIN busy loops Git-commit: 26ebd9c734d5b807055c333b29504b05fe971185 Patch-mainline: v4.13-rc1 References: FATE#322643 bsc#1055900 If the function for checking whether there is OA buffer data available (during a poll or blocking read) has false positives then we want to avoid a situation where the subsequent read() returns EAGAIN (after a more accurate check) followed by a poll() immediately reporting the same false positive POLLIN event and effectively maintaining a busy loop until there really is data. This makes sure that we clear the .pollin event status whenever we return EAGAIN to userspace which will throttle subsequent POLLIN events and repeated attempts to read to the 5ms intervals of the hrtimer callback we have. Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld Link: http://patchwork.freedesktop.org/patch/msgid/20170511154345.962-3-lionel.g.landwerlin@intel.com Signed-off-by: Chris Wilson Acked-by: Takashi Iwai --- drivers/gpu/drm/i915/i915_perf.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -1351,7 +1351,15 @@ static ssize_t i915_perf_read(struct fil mutex_unlock(&dev_priv->perf.lock); } - if (ret >= 0) { + /* We allow the poll checking to sometimes report false positive POLLIN + * events where we might actually report EAGAIN on read() if there's + * not really any data available. In this situation though we don't + * want to enter a busy loop between poll() reporting a POLLIN event + * and read() returning -EAGAIN. Clearing the oa.pollin state here + * effectively ensures we back off until the next hrtimer callback + * before reporting another POLLIN event. + */ + if (ret >= 0 || ret == -EAGAIN) { /* Maybe make ->pollin per-stream state if we support multiple * concurrent streams in the future. */