[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20141027.163116.627611711460671434.davem@davemloft.net>
Date: Mon, 27 Oct 2014 16:31:16 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: dvhart@...ux.intel.com
Cc: linux-kernel@...r.kernel.org, dvhart@...radead.org
Subject: Re: futex testsuite suggestion...
From: Darren Hart <dvhart@...ux.intel.com>
Date: Mon, 27 Oct 2014 13:29:14 -0700
> On 10/27/14 12:56, David Miller wrote:
>> I'd like to suggest that you add a test that triggers transparent
>> hugepages, because if an architecture doesn't implement
>> __get_user_pages_fast() such futexes cause a machine to hang.
>>
>> I hacked up something simple that took the existing performance
>> test and made it operate in a register allocated using memalign().
>>
>> I would suggest doing a memalign(HUGEPAGE_SIZE, HUGEPAGE_SIZE) then
>> iterating running a futex test within each normal page within that
>> hugepage.
>
> Do you want this option for the performance tests, or would a less
> intensive functional test be sufficient?
I think a functional test is sufficient.
> I'm perfectly happy to add such a test. I'm currently buried under a
> number of other things that have resulted in futextests suffering
> somewhat. So a couple of things to help make this happen:
>
> 1) Could you send me your hacked up test, in whatever condition?
See at the end of this email.
> 2) I'm more than happy to accept patches, but I do understand why you
> might prefer to have someone else write it :-)
I could find time to work on this. :)
diff --git a/performance/harness.h b/performance/harness.h
index a395492..5cfd09b 100644
--- a/performance/harness.h
+++ b/performance/harness.h
@@ -38,6 +38,7 @@
#include <limits.h>
#include <pthread.h>
#include <stdio.h>
+#include <malloc.h>
#include <sys/times.h>
#include "logging.h"
@@ -102,35 +103,39 @@ static void * locktest_thread(void * dummy)
static int locktest(void locktest_function(futex_t * ptr, int loops),
int iterations, int threads)
{
- struct locktest_shared shared;
+ struct locktest_shared *shared;
pthread_t thread[threads];
+ void *buf;
int i;
clock_t before, after;
struct tms tms_before, tms_after;
int wall, user, system;
double tick;
- barrier_init(&shared.barrier_before, threads);
- barrier_init(&shared.barrier_after, threads);
- shared.locktest_function = locktest_function;
- shared.loops = iterations / threads;
- shared.futex = 0;
+ buf = memalign(8 * 1024 * 1024, 8 * 1024 * 1024);
+ shared = (buf + (8 * 1024 * 1024) - sizeof(*shared));
+
+ barrier_init(&shared->barrier_before, threads);
+ barrier_init(&shared->barrier_after, threads);
+ shared->locktest_function = locktest_function;
+ shared->loops = iterations / threads;
+ shared->futex = 0;
for (i = 0; i < threads; i++)
if (pthread_create(thread + i, NULL, locktest_thread,
- &shared)) {
+ shared)) {
error("pthread_create\n", errno);
/* Could not create thread; abort */
- barrier_unblock(&shared.barrier_before, -1);
+ barrier_unblock(&shared->barrier_before, -1);
while (--i >= 0)
pthread_join(thread[i], NULL);
print_result(RET_ERROR);
return RET_ERROR;
}
- barrier_wait(&shared.barrier_before);
+ barrier_wait(&shared->barrier_before);
before = times(&tms_before);
- barrier_unblock(&shared.barrier_before, 1);
- barrier_wait(&shared.barrier_after);
+ barrier_unblock(&shared->barrier_before, 1);
+ barrier_wait(&shared->barrier_after);
after = times(&tms_after);
wall = after - before;
user = tms_after.tms_utime - tms_before.tms_utime;
@@ -139,12 +144,12 @@ static int locktest(void locktest_function(futex_t * ptr, int loops),
info("%.2fs user, %.2fs system, %.2fs wall, %.2f cores\n",
user * tick, system * tick, wall * tick,
wall ? (user + system) * 1. / wall : 1.);
- barrier_unblock(&shared.barrier_after, 1);
+ barrier_unblock(&shared->barrier_after, 1);
for (i = 0; i < threads; i++)
pthread_join(thread[i], NULL);
printf("Result: %.0f Kiter/s\n",
- (threads * shared.loops) / (wall * tick * 1000));
+ (threads * shared->loops) / (wall * tick * 1000));
return RET_PASS;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists