public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
Date: Fri, 27 Mar 2020 15:02:57 -0700	[thread overview]
Message-ID: <87o8shsbfy.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20200327205642.GC9553@orsosgc001.amr.corp.intel.com>

On Fri, 27 Mar 2020 13:56:42 -0700, Umesh Nerlige Ramappa wrote:
>
> On Thu, Mar 26, 2020 at 09:42:50PM -0700, Ashutosh Dixit wrote:
> > Add a test for OA data non-blocking reads using buffers smaller than
> > the available data. This test would fail for perf revisions < 5
> > because poll would block even when data was available. Therefore the
> > amount of data read was limited by the buffer size and the timer
> > interval and it was impossible to read all available data. This issue
> > is fixed in perf revision 5.
> >
> > v2: Complete rewrite, make test fail on existing kernels (Lionel)

/snip/

> > +	while (igt_nsec_elapsed(&ts) < test_duration) {
> > +		struct timespec poll_wait = {
> > +			.tv_sec = 0,
> > +			.tv_nsec = (test_duration - igt_nsec_elapsed(&ts)),
> > +		};
> > +		struct pollfd pollfd = { .fd = stream_fd, .events = POLLIN };
> > +		int ret;
> > +
> > +		ret = ppoll(&pollfd, 1, &poll_wait, NULL);
>
> when poll_wait reaches a value less than the default hrtimer poll period,
> poll will start timing out. I think the timeout will itself not set the
> POLLIN event, so that many reports will never be read.

Actually, poll timing out will just run in the loop running faster and
faster, so it will be busy spinning but will read data only when the timer
has fired and updated the tail pointer. So I think all reports will still
be read.

But that's a good point, what is the purpose of the timeout anyway? Why not
just have the poll unblock off the 5 ms timer? I will post a v3 with just
an infinite timeout and reducing data match requirement to 80%.

> the expected reports calculated here (and in other igt tests) do not take
> context switch reports into account. Do you think we can run into a
> situation where our calculations may go wrong due to large number of
> context switches? thoughts?

Well for IGT's mostly there is nothing else except the IGT running so maybe
it's ok? So what data is being collected when the GPU is idle, just some
periodic data?

Thanks!
--
Ashutosh
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2020-03-27 22:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-27  4:42 [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Ashutosh Dixit
2020-03-27  4:50 ` Dixit, Ashutosh
2020-03-27 16:09   ` Lionel Landwerlin
2020-03-27 19:03     ` Dixit, Ashutosh
2020-03-27 19:06       ` Lionel Landwerlin
2020-03-27 19:49         ` Dixit, Ashutosh
2020-03-31  6:06           ` Dixit, Ashutosh
2020-03-31  7:36             ` Lionel Landwerlin
2020-03-31  7:48               ` Dixit, Ashutosh
2020-04-03  1:19                 ` Dixit, Ashutosh
2020-03-27  5:23 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/perf: add a test for OA data polling reads using "small" buffers (rev2) Patchwork
2020-03-27 15:19 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2020-03-27 20:56 ` [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Umesh Nerlige Ramappa
2020-03-27 22:02   ` Dixit, Ashutosh [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-03-27 22:29 Ashutosh Dixit
2020-03-26  5:42 Ashutosh Dixit
2020-03-26  9:02 ` Lionel Landwerlin
2020-03-27  4:08   ` Dixit, Ashutosh

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=87o8shsbfy.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=igt-dev@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