Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3] prime_mmap_coherency: Add return error tests for prime sync ioctl
Date: Fri, 18 Mar 2016 19:11:18 +0100	[thread overview]
Message-ID: <20160318181118.GN14170@phenom.ffwll.local> (raw)
In-Reply-To: <1458324536-4550-1-git-send-email-tiago.vignatti@intel.com>

On Fri, Mar 18, 2016 at 03:08:56PM -0300, Tiago Vignatti wrote:
> This patch adds ioctl-errors subtest to be used for exercising prime sync ioctl
> errors.
> 
> The subtest constantly interrupts via signals a function doing concurrent blit
> to stress out the right usage of prime_sync_*, making sure these ioctl errors
> are handled accordingly. Important to note that in case of failure (e.g. in a
> case where the ioctl wouldn't try again in a return error) this test does not
> reliably catch the problem with 100% of accuracy.
> 
> v2: fix prime sync direction when reading mmap'ed file.
> v3: change the upper bound using time rather than loops
>  
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>

I'm probably blind, but where is the reviewed kernel patch for this? If
it's somewhere hidden, please resubmit with all the whizzbang stuff needed
for merging added ;-)

Thanks, Daniel

> ---
>  tests/prime_mmap_coherency.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 89 insertions(+)
> 
> diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
> index 180d8a4..d2b2a4f 100644
> --- a/tests/prime_mmap_coherency.c
> +++ b/tests/prime_mmap_coherency.c
> @@ -180,6 +180,90 @@ static void test_write_flush(bool expect_stale_cache)
>  	munmap(ptr_cpu, width * height);
>  }
>  
> +static void blit_and_cmp(void)
> +{
> +	drm_intel_bo *bo_1;
> +	drm_intel_bo *bo_2;
> +	uint32_t *ptr_cpu;
> +	uint32_t *ptr2_cpu;
> +	int dma_buf_fd, dma_buf2_fd, i;
> +	int local_fd;
> +	drm_intel_bufmgr *local_bufmgr;
> +	struct intel_batchbuffer *local_batch;
> +
> +	/* recreate process local variables */
> +	local_fd = drm_open_driver(DRIVER_INTEL);
> +	local_bufmgr = drm_intel_bufmgr_gem_init(local_fd, 4096);
> +	igt_assert(local_bufmgr);
> +
> +	local_batch = intel_batchbuffer_alloc(local_bufmgr, intel_get_drm_devid(local_fd));
> +	igt_assert(local_batch);
> +
> +	bo_1 = drm_intel_bo_alloc(local_bufmgr, "BO 1", width * height * 4, 4096);
> +	dma_buf_fd = prime_handle_to_fd_for_mmap(local_fd, bo_1->handle);
> +	igt_skip_on(errno == EINVAL);
> +
> +	ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
> +			MAP_SHARED, dma_buf_fd, 0);
> +	igt_assert(ptr_cpu != MAP_FAILED);
> +
> +	bo_2 = drm_intel_bo_alloc(local_bufmgr, "BO 2", width * height * 4, 4096);
> +	dma_buf2_fd = prime_handle_to_fd_for_mmap(local_fd, bo_2->handle);
> +
> +	ptr2_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
> +			MAP_SHARED, dma_buf2_fd, 0);
> +	igt_assert(ptr2_cpu != MAP_FAILED);
> +
> +	/* Fill up BO 1 with '1's and BO 2 with '0's */
> +	prime_sync_start(dma_buf_fd, true);
> +	memset(ptr_cpu, 0x11, width * height);
> +	prime_sync_end(dma_buf_fd, true);
> +
> +	prime_sync_start(dma_buf2_fd, true);
> +	memset(ptr2_cpu, 0x00, width * height);
> +	prime_sync_end(dma_buf2_fd, true);
> +
> +	/* Copy BO 1 into BO 2, using blitter. */
> +	intel_copy_bo(local_batch, bo_2, bo_1, width * height);
> +	usleep(0); /* let someone else claim the mutex */
> +
> +	/* Compare BOs. If prime_sync_* were executed properly, the caches
> +	 * should be synced. */
> +	prime_sync_start(dma_buf2_fd, false);
> +	for (i = 0; i < (width * height) / 4; i++)
> +		igt_fail_on_f(ptr2_cpu[i] != 0x11111111, "Found 0x%08x at offset 0x%08x\n", ptr2_cpu[i], i);
> +	prime_sync_end(dma_buf2_fd, false);
> +
> +	drm_intel_bo_unreference(bo_1);
> +	drm_intel_bo_unreference(bo_2);
> +	munmap(ptr_cpu, width * height);
> +	munmap(ptr2_cpu, width * height);
> +}
> +
> +/*
> + * Constantly interrupt concurrent blits to stress out prime_sync_* and make
> + * sure these ioctl errors are handled accordingly.
> + *
> + * Important to note that in case of failure (e.g. in a case where the ioctl
> + * wouldn't try again in a return error) this test does not reliably catch the
> + * problem with 100% of accuracy.
> + */
> +static void test_ioctl_errors(void)
> +{
> +	int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
> +
> +	igt_fork_signal_helper();
> +	for (int num_children = 1; num_children <= 8 *ncpus; num_children <<= 1) {
> +		igt_fork(child, num_children) {
> +			struct timespec start = {};
> +			while (igt_nsec_elapsed(&start) <= num_children)
> +				blit_and_cmp();
> +		}
> +		igt_waitchildren();
> +	}
> +	igt_stop_signal_helper();
> +}
> +
>  int main(int argc, char **argv)
>  {
>  	int i;
> @@ -235,6 +319,11 @@ int main(int argc, char **argv)
>  		igt_fail_on_f(!stale, "couldn't find any stale cache lines\n");
>  	}
>  
> +	igt_subtest("ioctl-errors") {
> +		igt_info("exercising concurrent blit to get ioctl errors\n");
> +		test_ioctl_errors();
> +	}
> +
>  	igt_fixture {
>  		intel_batchbuffer_free(batch);
>  		drm_intel_bufmgr_destroy(bufmgr);
> -- 
> 2.1.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-03-18 18:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <56E71D36.1060205@intel.com>
2016-03-17 18:18 ` [PATCH] prime_mmap_coherency: Add return error tests for prime sync ioctl Tiago Vignatti
2016-03-17 21:01   ` Chris Wilson
2016-03-17 21:15     ` Tiago Vignatti
2016-03-17 21:18     ` [PATCH v2] " Tiago Vignatti
2016-03-18  9:44       ` Chris Wilson
2016-03-18  9:53         ` [Intel-gfx] " Chris Wilson
2016-03-18 18:08         ` [PATCH v3] " Tiago Vignatti
2016-03-18 18:11           ` Daniel Vetter [this message]
2016-03-18 18:17             ` Tiago Vignatti
2016-03-18 20:43           ` Chris Wilson

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=20160318181118.GN14170@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tiago.vignatti@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