[Intel-gfx] [PATCH] tests/gem_evict_everything: Use bo_count instead of count where intended

[Daniel Vetter]

On Fri, Dec 06, 2013 at 12:33:28PM +0000, Tvrtko Ursulin wrote:
> On Fri, 2013-12-06 at 13:12 +0100, Daniel Vetter wrote:
> > On Fri, Dec 06, 2013 at 11:37:49AM +0000, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > > 
> > > Don't see that it causes a problem but it looks it was intended
> > > to use bo_count at these places.
> > > 
> > > Also using count to determine number of processes does not make
> > > sense unless thousands of cores.
> > > 
> > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > > ---
> > >  tests/gem_evict_everything.c | 12 +++++-------
> > >  1 file changed, 5 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/tests/gem_evict_everything.c b/tests/gem_evict_everything.c
> > > index 41abef7..90c3ae1 100644
> > > --- a/tests/gem_evict_everything.c
> > > +++ b/tests/gem_evict_everything.c
> > > @@ -135,8 +135,6 @@ static void exchange_uint32_t(void *array, unsigned i, unsigned j)
> > >  	i_arr[j] = i_tmp;
> > >  }
> > >  
> > > -#define min(a, b) ((a) < (b) ? (a) : (b))
> > > -
> > >  #define INTERRUPTIBLE	(1 << 0)
> > >  #define SWAPPING	(1 << 1)
> > >  #define DUP_DRMFD	(1 << 2)
> > > @@ -168,7 +166,7 @@ static void forked_evictions(int fd, int size, int count,
> > >  	for (n = 0; n < bo_count; n++)
> > >  		bo[n] = gem_create(fd, size);
> > >  
> > > -	igt_fork(i, min(count, min(num_threads * 5, 12))) {
> > > +	igt_fork(i, num_threads * 4) {
> > 
> > You've killed the min( , 12) here ... that'll hurt on big desktops.
> > Otherwise patch looks good.
> 
> It was hard for me to know what kind of stress was desired there.
> Thinking of typical cases, single core single thread gives five
> "stressers", more typical 2x1 gives 10. So it seems the whole
> calculation will typically be between 10 and 12, 5 and 12 conditionally.
> Which almost sounds a bit pointless.. I mean to have the calculation as
> it was at all.

Well, igt stresstests are mostly random whacking until I'm fairly happy on
a set of machines. But If you kill that max 12 runtime on bigger stuff
will go through the roof for sure. And even on my really old single-core
machines it's still ok. I suspect due to the thrashing the depency is
fairly non-linear.

Longer-term I want to speed up all these memory thrashing tests by
mlocking most of main memory and so removing it from consideration. But
that's a bit of work to set up and roll out across all tests.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch