Re: [PATCH v6] igt/gem_trtt: Exercise the TRTT hardware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 3/18/2016 4:02 PM, Chris Wilson wrote:
On Fri, Mar 18, 2016 at 03:22:51PM +0530, Goel, Akash wrote:


On 3/18/2016 2:52 PM, Chris Wilson wrote:
On Fri, Mar 18, 2016 at 02:31:23PM +0530, Goel, Akash wrote:

Hopefully final comments!

Missed EINTR handling during evict, If you repeat the busy/hang tests
within the igt_fork_signal_helper(); igt_stop_signal_helper() that
should cover catching an inopportune signal.

Fine will add, thanks for suggesting this
So the signal will interrupt the Driver, which would be waiting for
the vma unbind to complete, from the eviction path.

Right, and we will report the error back to userspace as EINTR and
userspace will restart the syscall and we expect it to succeed
(eventually). Just useful for flushing out the error handling.

Having just remembered how useful this might be, I just extended
gem_softpin for similar reasons:
+       igt_subtest("evict-active-interruptible") {
+               struct timespec start = {};
+               while (igt_seconds_elapsed(&start) < 20)
+                       test_evict_active(fd);
+       }
Thanks I just tested the interruptible versions like this :-

+	igt_fork_signal_helper();
+	igt_subtest("evict_active-interruptible")
+		 test_evict_active();

The point about looping is to try and ensure that every possible code
path is interrupted (since we only interrupt every 2us and the code paths
tend to be shorter than than!).

Thanks, will follow the gem_softpin.c example.

I hope you meant 2ms here & not 2us, since the signal_helper_process is sending signals at the ~500 Hz rate.

Best regards
Akash

So we repeat the test in the vain hope of hitting something else.


+	igt_subtest("evict_hang-interruptible")
+		test_evict_hang();
+	igt_stop_signal_helper();

Actually the hanging object test implicitly exercises the
interruption case (otherwise the test won't pass), error recovery as
a part of GPU reset wakes up/interrupts the waiters.

But only in one spot :)
-Chris

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux