Message ID | 20190322092155.1656-9-chris@chris-wilson.co.uk (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [i-g-t,01/24] i915/gem_exec_latency: Measure the latency of context switching | expand |
On 22/03/2019 09:21, Chris Wilson wrote: > CI complains that the exhaustive test of trying every size up to the > limit is too slow, so add a simple test that tries to submit one > extreme batch buffer and check all the relocations land. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105555 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > --- > tests/i915/gem_exec_big.c | 70 ++++++++++++++++++++++++++++++------ > tests/intel-ci/blacklist.txt | 1 + > 2 files changed, 60 insertions(+), 11 deletions(-) > > diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c > index a15672f66..015f59e29 100644 > --- a/tests/i915/gem_exec_big.c > +++ b/tests/i915/gem_exec_big.c > @@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t reloc_ofs, unsigned flags, c > gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc); > gem_exec[0].alignment = 0; > gem_exec[0].offset = 0; > - gem_exec[0].flags = 0; > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; > gem_exec[0].rsvd1 = 0; > gem_exec[0].rsvd2 = 0; > > @@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, uint64_t batch_size, unsigned flags, > gem_exec[0].handle = handle; > gem_exec[0].relocation_count = nreloc; > gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc); > + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; > > memset(&execbuf, 0, sizeof(execbuf)); > execbuf.buffers_ptr = to_user_pointer(gem_exec); > execbuf.buffer_count = 1; > - execbuf.batch_start_offset = 0; > - execbuf.batch_len = 8; > execbuf.flags = flags; > > /* Avoid hitting slowpaths in the reloc processing which might yield a > @@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, uint64_t batch_size, unsigned flags, > #undef reloc_ofs > } > > -igt_simple_main > +static void exhaustive(int fd) > { > uint32_t batch[2] = {MI_BATCH_BUFFER_END}; > uint64_t batch_size, max, ggtt_max, reloc_ofs; > - int fd; > - > - fd = drm_open_driver(DRIVER_INTEL); > - igt_require_gem(fd); > - > - use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8; > > max = 3 * gem_aperture_size(fd) / 4; > ggtt_max = 3 * gem_global_aperture_size(fd) / 4; > @@ -258,6 +251,61 @@ igt_simple_main > else > batch_size *= 2; > } > +} > + > +static void single(int i915) > +{ > + const uint32_t bbe = MI_BATCH_BUFFER_END; > + uint64_t batch_size, limit; > + uint32_t handle; > + void *ptr; > + > + batch_size = (intel_get_avail_ram_mb() - 128) << 20; /* CI slack */ Slack big enough? Sounds risky.. > + limit = gem_aperture_size(i915) - (256 << 10); /* low pages reserved */ > + if (!gem_uses_full_ppgtt(i915)) > + limit = 3 * limit / 4; > + > + batch_size = min(batch_size, limit); > + batch_size = ALIGN(batch_size, 4096); > + igt_info("Submitting a %'"PRId64"MiB batch, %saperture size %'"PRId64"MiB\n", > + batch_size >> 20, > + gem_uses_full_ppgtt(i915) ? "" : "shared ", > + gem_aperture_size(i915) >> 20); > + intel_require_memory(1, batch_size, CHECK_RAM); > + > + handle = gem_create(i915, batch_size); > + gem_write(i915, handle, 0, &bbe, sizeof(bbe)); > + > + if (!FORCE_PREAD_PWRITE && gem_has_llc(i915)) > + ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, PROT_READ); > + else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915)) > + ptr = __gem_mmap__wc(i915, handle, 0, batch_size, PROT_READ); > + else > + ptr = NULL; > + > + execN(i915, handle, batch_size, 0, ptr); > + > + if (ptr) > + munmap(ptr, batch_size); > +} > + > +igt_main > +{ > + int i915 = -1; > + > + igt_fixture { > + i915 = drm_open_driver(DRIVER_INTEL); > + igt_require_gem(i915); > + > + use_64bit_relocs = intel_gen(intel_get_drm_devid(i915)) >= 8; > + } > + > + igt_subtest("single") > + single(i915); > + > + igt_subtest("exhaustive") > + exhaustive(i915); > > - close(fd); > + igt_fixture > + close(i915); > } > diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt > index a2101ae71..ae61efe3f 100644 > --- a/tests/intel-ci/blacklist.txt > +++ b/tests/intel-ci/blacklist.txt > @@ -28,6 +28,7 @@ igt@gem_ctx_thrash(@.*)? > igt@gem_evict_alignment(@.*)? > igt@gem_evict_everything(@.*)? > igt@gem_exec_alignment@(?!.*single).* > +igt@gem_exec_big@(?!.*single).* > igt@gem_exec_capture@many-(?!4K-).* > igt@gem_exec_fence@(?!.*basic).* > igt@gem_exec_flush@(?!.*basic).* > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Regards, Tvrtko
Quoting Tvrtko Ursulin (2019-03-26 10:06:37) > > On 22/03/2019 09:21, Chris Wilson wrote: > > +static void single(int i915) > > +{ > > + const uint32_t bbe = MI_BATCH_BUFFER_END; > > + uint64_t batch_size, limit; > > + uint32_t handle; > > + void *ptr; > > + > > + batch_size = (intel_get_avail_ram_mb() - 128) << 20; /* CI slack */ > > Slack big enough? Sounds risky.. How big is Java? Bigger than you can possibly imagine. Why is it running during igt? CI only know. I have no idea, avail_ram_mb() is meant to be able to say how much memory we could use, but then Java keeps on stealing more. We could mlock it I guess, but the end result is the same, Java is forced into swap and we risk page allocation failures. -Chris
diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c index a15672f66..015f59e29 100644 --- a/tests/i915/gem_exec_big.c +++ b/tests/i915/gem_exec_big.c @@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t reloc_ofs, unsigned flags, c gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc); gem_exec[0].alignment = 0; gem_exec[0].offset = 0; - gem_exec[0].flags = 0; + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; gem_exec[0].rsvd1 = 0; gem_exec[0].rsvd2 = 0; @@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, uint64_t batch_size, unsigned flags, gem_exec[0].handle = handle; gem_exec[0].relocation_count = nreloc; gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc); + gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; memset(&execbuf, 0, sizeof(execbuf)); execbuf.buffers_ptr = to_user_pointer(gem_exec); execbuf.buffer_count = 1; - execbuf.batch_start_offset = 0; - execbuf.batch_len = 8; execbuf.flags = flags; /* Avoid hitting slowpaths in the reloc processing which might yield a @@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, uint64_t batch_size, unsigned flags, #undef reloc_ofs } -igt_simple_main +static void exhaustive(int fd) { uint32_t batch[2] = {MI_BATCH_BUFFER_END}; uint64_t batch_size, max, ggtt_max, reloc_ofs; - int fd; - - fd = drm_open_driver(DRIVER_INTEL); - igt_require_gem(fd); - - use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8; max = 3 * gem_aperture_size(fd) / 4; ggtt_max = 3 * gem_global_aperture_size(fd) / 4; @@ -258,6 +251,61 @@ igt_simple_main else batch_size *= 2; } +} + +static void single(int i915) +{ + const uint32_t bbe = MI_BATCH_BUFFER_END; + uint64_t batch_size, limit; + uint32_t handle; + void *ptr; + + batch_size = (intel_get_avail_ram_mb() - 128) << 20; /* CI slack */ + limit = gem_aperture_size(i915) - (256 << 10); /* low pages reserved */ + if (!gem_uses_full_ppgtt(i915)) + limit = 3 * limit / 4; + + batch_size = min(batch_size, limit); + batch_size = ALIGN(batch_size, 4096); + igt_info("Submitting a %'"PRId64"MiB batch, %saperture size %'"PRId64"MiB\n", + batch_size >> 20, + gem_uses_full_ppgtt(i915) ? "" : "shared ", + gem_aperture_size(i915) >> 20); + intel_require_memory(1, batch_size, CHECK_RAM); + + handle = gem_create(i915, batch_size); + gem_write(i915, handle, 0, &bbe, sizeof(bbe)); + + if (!FORCE_PREAD_PWRITE && gem_has_llc(i915)) + ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, PROT_READ); + else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915)) + ptr = __gem_mmap__wc(i915, handle, 0, batch_size, PROT_READ); + else + ptr = NULL; + + execN(i915, handle, batch_size, 0, ptr); + + if (ptr) + munmap(ptr, batch_size); +} + +igt_main +{ + int i915 = -1; + + igt_fixture { + i915 = drm_open_driver(DRIVER_INTEL); + igt_require_gem(i915); + + use_64bit_relocs = intel_gen(intel_get_drm_devid(i915)) >= 8; + } + + igt_subtest("single") + single(i915); + + igt_subtest("exhaustive") + exhaustive(i915); - close(fd); + igt_fixture + close(i915); } diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt index a2101ae71..ae61efe3f 100644 --- a/tests/intel-ci/blacklist.txt +++ b/tests/intel-ci/blacklist.txt @@ -28,6 +28,7 @@ igt@gem_ctx_thrash(@.*)? igt@gem_evict_alignment(@.*)? igt@gem_evict_everything(@.*)? igt@gem_exec_alignment@(?!.*single).* +igt@gem_exec_big@(?!.*single).* igt@gem_exec_capture@many-(?!4K-).* igt@gem_exec_fence@(?!.*basic).* igt@gem_exec_flush@(?!.*basic).*
CI complains that the exhaustive test of trying every size up to the limit is too slow, so add a simple test that tries to submit one extreme batch buffer and check all the relocations land. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105555 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- tests/i915/gem_exec_big.c | 70 ++++++++++++++++++++++++++++++------ tests/intel-ci/blacklist.txt | 1 + 2 files changed, 60 insertions(+), 11 deletions(-)