From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] tests/gem_evict_everything: Use bo_count instead of count where intended
Date: Fri, 06 Dec 2013 12:33:28 +0000 [thread overview]
Message-ID: <1386333208.6066.24.camel@tursulin-linux.isw.intel.com> (raw)
In-Reply-To: <20131206121240.GL27344@phenom.ffwll.local>
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@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@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.
Tvrtko
next prev parent reply other threads:[~2013-12-06 12:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 11:37 [PATCH] tests/gem_evict_everything: Use bo_count instead of count where intended Tvrtko Ursulin
2013-12-06 12:12 ` Daniel Vetter
2013-12-06 12:33 ` Tvrtko Ursulin [this message]
2013-12-06 13:46 ` Daniel Vetter
2013-12-06 14:04 ` Tvrtko Ursulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1386333208.6066.24.camel@tursulin-linux.isw.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=daniel@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox