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

[Tvrtko Ursulin]

On Fri, 2013-12-06 at 14:46 +0100, Daniel Vetter wrote:
> 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.

OK, I'll send a version with that clamp put back in.

Tvrtko