From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tvrtko Ursulin Subject: Re: [PATCH] tests/gem_evict_everything: Use bo_count instead of count where intended Date: Fri, 06 Dec 2013 14:04:30 +0000 Message-ID: <1386338670.6066.29.camel@tursulin-linux.isw.intel.com> References: <1386329869-12379-1-git-send-email-tvrtko.ursulin@linux.intel.com> <20131206121240.GL27344@phenom.ffwll.local> <1386333208.6066.24.camel@tursulin-linux.isw.intel.com> <20131206134623.GN27344@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 0E773FBB7B for ; Fri, 6 Dec 2013 06:04:33 -0800 (PST) In-Reply-To: <20131206134623.GN27344@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Daniel Vetter Cc: Intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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 > > > > > > > > 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 > > > > --- > > > > 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