[01/19] i915/gem_ppgtt: Estimate resource usage and bail if it means swapping!

Submitted by Chris Wilson on March 8, 2019, 6:11 p.m.

Details

Message ID 20190308181129.15562-1-chris@chris-wilson.co.uk
State Accepted
Commit 4e7296aa879350b10a216b88fa7f44d919765765
Headers show
Series "Series without cover letter" ( rev: 1 ) in IGT (deprecated)

Not browsing as part of any series.

Commit Message

Chris Wilson March 8, 2019, 6:11 p.m.
fi-kbl-guc's swap ran dry while running blt-vs-render-ctxN, which is
midly concerning but conceivable as we never checked there was enough
memory to run the test to begin with.

Each child needs to keep its own surface and possible a pair of logical
contexts (one for rcs and one for bcs) so check that there is enough
memory to allow all children to co-exist. During execution, we require
another surface and batch, but these are temporary and so should fit
fine with a small amount of thrashing on the boundary.

References: https://bugs.freedesktop.org/show_bug.cgi?id=109801
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 tests/i915/gem_ppgtt.c | 6 ++++++
 1 file changed, 6 insertions(+)

Patch hide | download patch | download mbox

diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
index 11ca31e74..9409bef14 100644
--- a/tests/i915/gem_ppgtt.c
+++ b/tests/i915/gem_ppgtt.c
@@ -91,8 +91,14 @@  static void fork_rcs_copy(int timeout, uint32_t final,
 #define CREATE_CONTEXT 0x1
 {
 	igt_render_copyfunc_t render_copy;
+	uint64_t mem_per_child;
 	int devid;
 
+	mem_per_child = SIZE;
+	if (flags & CREATE_CONTEXT)
+		mem_per_child += 2 * 128 * 1024; /* rough context sizes */
+	intel_require_memory(mem_per_child, count, CHECK_RAM);
+
 	for (int child = 0; child < count; child++) {
 		int fd = drm_open_driver(DRIVER_INTEL);
 		drm_intel_bufmgr *bufmgr;

Comments

Chris Wilson <chris@chris-wilson.co.uk> writes:

> fi-kbl-guc's swap ran dry while running blt-vs-render-ctxN, which is
> midly concerning but conceivable as we never checked there was enough
> memory to run the test to begin with.
>
> Each child needs to keep its own surface and possible a pair of logical
> contexts (one for rcs and one for bcs) so check that there is enough
> memory to allow all children to co-exist. During execution, we require
> another surface and batch, but these are temporary and so should fit
> fine with a small amount of thrashing on the boundary.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109801
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  tests/i915/gem_ppgtt.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
> index 11ca31e74..9409bef14 100644
> --- a/tests/i915/gem_ppgtt.c
> +++ b/tests/i915/gem_ppgtt.c
> @@ -91,8 +91,14 @@ static void fork_rcs_copy(int timeout, uint32_t final,
>  #define CREATE_CONTEXT 0x1
>  {
>  	igt_render_copyfunc_t render_copy;
> +	uint64_t mem_per_child;
>  	int devid;
>  
> +	mem_per_child = SIZE;
> +	if (flags & CREATE_CONTEXT)
> +		mem_per_child += 2 * 128 * 1024; /* rough context sizes */

Someday libify this so that we give num context and size per each?
Just that the modern gens eat more so we could tweak per gen instead
of going with the max estimate. Regardless,

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>


> +	intel_require_memory(mem_per_child, count, CHECK_RAM);
> +
>  	for (int child = 0; child < count; child++) {
>  		int fd = drm_open_driver(DRIVER_INTEL);
>  		drm_intel_bufmgr *bufmgr;
> -- 
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Mika Kuoppala (2019-03-11 10:04:05)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> > +     mem_per_child = SIZE;
> > +     if (flags & CREATE_CONTEXT)
> > +             mem_per_child += 2 * 128 * 1024; /* rough context sizes */
> 
> Someday libify this so that we give num context and size per each?
> Just that the modern gens eat more so we could tweak per gen instead
> of going with the max estimate. Regardless,

You mean keep guessing something the kernel knows? If only we had an
interface for that ;)
-Chris