All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH igt 2/3] benchmarks/gem_syslatency: Apply vmpressure, measure page allocation
Date: Wed, 27 Sep 2017 11:52:42 +0300	[thread overview]
Message-ID: <1506502362.5505.30.camel@linux.intel.com> (raw)
In-Reply-To: <20170925202643.340-2-chris@chris-wilson.co.uk>

On Mon, 2017-09-25 at 21:26 +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  benchmarks/gem_syslatency.c | 86 +++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 83 insertions(+), 3 deletions(-)
> 
> diff --git a/benchmarks/gem_syslatency.c b/benchmarks/gem_syslatency.c
> index 4ed23638..b8788497 100644
> --- a/benchmarks/gem_syslatency.c
> +++ b/benchmarks/gem_syslatency.c
> @@ -29,6 +29,7 @@
>  #include <stdio.h>
>  #include <string.h>
>  #include <fcntl.h>
> +#include <ftw.h>
>  #include <inttypes.h>
>  #include <pthread.h>
>  #include <sched.h>
> @@ -51,6 +52,7 @@ static volatile int done;
>  struct gem_busyspin {
>  	pthread_t thread;
>  	unsigned long count;
> +	bool leak;
>  };

I know we all binary arithmetic, but can I still ask


#define M()
#define K()

Or something.

>  
>  struct sys_wait {
> @@ -93,6 +95,7 @@ static void *gem_busyspin(void *arg)
>  	struct gem_busyspin *bs = arg;
>  	struct drm_i915_gem_execbuffer2 execbuf;
>  	struct drm_i915_gem_exec_object2 obj;
> +	const unsigned sz = bs->leak ? 16 << 20 : 4 << 10;

Beause, this is quite OK still.

> @@ -180,6 +188,33 @@ static void *sys_wait(void *arg)
>  	return NULL;
>  }
>  
> +static void *sys_thp_alloc(void *arg)
> +{
> +	struct sys_wait *w = arg;
> +	struct timespec now;
> +
> +	clock_gettime(CLOCK_MONOTONIC, &now);
> +	while (!done) {
> +		const size_t sz = 2 << 20;
> +		const struct timespec start = now;
> +		void *ptr;
> +
> +		ptr = mmap(NULL, sz,
> +			   PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,
> +			   -1, 0);
> +		assert(ptr != MAP_FAILED);
> +		madvise(ptr, sz, MADV_HUGEPAGE);
> +		for (int page = 0; page < 2 << 20 >> 12; page++)
> +			*((volatile uint32_t *)ptr + (page << 12 >> 2)) = 0;

But what's the point in this iteration, we iterate from 0 to 512 page
index (sz/PAGE_SIZE would be so much easier) and then write to to not
each page but interleave four page writes per page and 3/4 of pages
never get written? If this is intentional, please drop a comment.

Other than that,

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-09-27  8:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25 20:26 [PATCH igt 1/3] benchmark/gem_busy: Compare polling with syncobj_wait Chris Wilson
2017-09-25 20:26 ` [PATCH igt 2/3] benchmarks/gem_syslatency: Apply vmpressure, measure page allocation Chris Wilson
2017-09-27  8:52   ` Joonas Lahtinen [this message]
2017-09-27  9:36     ` Chris Wilson
2017-09-27  9:41     ` Chris Wilson
2017-09-27 10:02       ` Joonas Lahtinen
2017-09-27 11:07         ` Chris Wilson
2017-09-25 20:26 ` [PATCH igt 3/3] benchmarks/gem_exec_fault: Update for tryhard kernels Chris Wilson
2017-09-26 10:56   ` Matthew Auld
2017-09-25 21:06 ` ✓ Fi.CI.BAT: success for series starting with [1/3] benchmark/gem_busy: Compare polling with syncobj_wait Patchwork
2017-09-26  2:35 ` ✓ Fi.CI.IGT: " Patchwork
2017-09-28  6:53 ` [PATCH igt 1/3] " Tvrtko Ursulin
2017-09-28  9:07   ` Chris Wilson
2017-09-28  9:16     ` Tvrtko Ursulin
2017-09-28  9:50       ` Chris Wilson

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=1506502362.5505.30.camel@linux.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.