From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id 38A4B6EA91 for ; Fri, 27 Mar 2020 22:02:58 +0000 (UTC) Date: Fri, 27 Mar 2020 15:02:57 -0700 Message-ID: <87o8shsbfy.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" In-Reply-To: <20200327205642.GC9553@orsosgc001.amr.corp.intel.com> References: <20200327044250.64274-1-ashutosh.dixit@intel.com> <20200327205642.GC9553@orsosgc001.amr.corp.intel.com> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Subject: Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" To: Umesh Nerlige Ramappa Cc: igt-dev@lists.freedesktop.org List-ID: 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