From: Darren Hart <dvhltc@us.ibm.com>
To: subrata@linux.vnet.ibm.com
Cc: ltp-list <ltp-list@lists.sourceforge.net>,
gowrishankar <gowrishankar.m@linux.vnet.ibm.com>
Subject: Re: [LTP] [PATCH][real-time] sched_footbal atomic start
Date: Thu, 25 Jun 2009 13:34:16 -0700 [thread overview]
Message-ID: <4A43DF48.3070808@us.ibm.com> (raw)
In-Reply-To: <1245921054.5542.49.camel@subratamodak.linux.ibm.com>
Subrata Modak wrote:
> On Thu, 2009-06-25 at 09:46 +0530, gowrishankar wrote:
>> Darren Hart wrote:
>>> The current barrier implementation results in the lowest priority thread
>>> actually starting the game (they are the last to be scheduled to call
>>> pthread_barrier_wait). This thread likely gets a priority boost as it
>>> holds
>>> the hb->lock for the futex associated with the barrier. This might lead
>>> to it
>>> running ahead of the defense threads.
>>> In fact, any sort of barrier or cond var implementation (short of a pi
>>> aware
>>> cond broadcast, which is not yet readily available) will result in a
>>> thundering
>>> herd situation when the FUTEX_WAKE_ALL syscall is issued, which can
>>> result in
>>> a short run of one or more offense threads while all the threads get to the
>>> RUNNABLE state.
>>>
>>> This patch removes the complex starting mechansims and replaces them with a
>>> simple atomic counter. All player threads are started and once the
>>> players_ready count reaches the total player count, the referee starts
>>> the game
>>> by setting the ball position to zero.
>>>
>>> Tested on two platforms (both x86_64, 4 and 8-way) for a combined total of
>>> 13,000 iterations with 0 failures.
>>>
>>> Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
>>>
>
> Thanks Darren. Long time LTP say updates to RT tests. What happened to
> the RT-Graphics tests that probably were in the pipeline ?
Hrm.... well.... I can't recall what those might have been. The only
graphics testing we do is really just functional testing using existing
tests like x11perf and specviewperf. We haven't written anything
specifically for -rt. Do you have any more detail on what this might
have been?
--
Darren
>
> Regards--
> Subrata
>
>> Acked-by: Gowrishankar <gowrishankar.m@in.ibm.com>
>>
>> Thanks.
>> Gowri
>>> Index: ltp/testcases/realtime/func/sched_football/sched_football.c
>>> ===================================================================
>>> --- ltp.orig/testcases/realtime/func/sched_football/sched_football.c
>>> 2009-06-24 11:49:16.000000000 -0700
>>> +++ ltp/testcases/realtime/func/sched_football/sched_football.c
>>> 2009-06-24 11:48:44.000000000 -0700
>>> @@ -47,9 +47,11 @@
>>> *
>>> * HISTORY
>>> * 2006-03-16 Reduced verbosity, non binary failure reporting,
>>> removal of
>>> - * crazy_fans thread, added game_length argument by Darren Hart.
>>> - * 2007-08-01 Remove all thread cleanup in favor of simply
>>> exiting.Various
>>> - * bugfixes and cleanups. -- Josh Triplett
>>> + * crazy_fans thread, added game_length argument by
>>> Darren Hart.
>>> + * 2007-08-01 Remove all thread cleanup in favor of simply
>>> exiting.Various
>>> + * bugfixes and cleanups. -- Josh Triplett
>>> + * 2009-06-23 Simplified atomic startup mechanism, avoiding
>>> thundering herd
>>> + * scheduling at the beginning of the game. -- Darren Hart
>>> *
>>> *****************************************************************************/
>>>
>>>
>>> @@ -71,11 +73,9 @@
>>> /* Here's the position of the ball */
>>> volatile int the_ball;
>>>
>>> -/* pthread_barrier for synchronization */
>>> -pthread_barrier_t barrier;
>>> -
>>> static int players_per_team = 0;
>>> static int game_length = DEF_GAME_LENGTH;
>>> +static atomic_t players_ready;
>>>
>>> void usage(void)
>>> {
>>> @@ -110,8 +110,7 @@
>>> /* This is the defensive team. They're trying to block the offense */
>>> void *thread_defense(void* arg)
>>> {
>>> - pthread_barrier_wait(&barrier);
>>> -
>>> + atomic_inc(&players_ready);
>>> /*keep the ball from being moved */
>>> while (1) {
>>> sched_yield(); /* let other defenders run */
>>> @@ -123,8 +122,7 @@
>>> /* This is the offensive team. They're trying to move the ball */
>>> void *thread_offense(void* arg)
>>> {
>>> - pthread_barrier_wait(&barrier);
>>> -
>>> + atomic_inc(&players_ready);
>>> while (1) {
>>> the_ball++; /* move the ball ahead one yard */
>>> sched_yield(); /* let other offensive players run */
>>> @@ -141,9 +139,9 @@
>>>
>>> gettimeofday(&start, NULL);
>>> now = start;
>>> - the_ball = 0;
>>>
>>> - pthread_barrier_wait(&barrier);
>>> + /* Start the game! */
>>> + the_ball = 0;
>>>
>>> /* Watch the game */
>>> while ((now.tv_sec - start.tv_sec) < game_length) {
>>> @@ -169,10 +167,7 @@
>>> if (players_per_team == 0)
>>> players_per_team = sysconf(_SC_NPROCESSORS_ONLN);
>>>
>>> - if ((i = pthread_barrier_init(&barrier, NULL, players_per_team*2 +
>>> 1))) {
>>> - printf("pthread_barrier_init failed: %s\n", strerror(i));
>>> - exit(i);
>>> - }
>>> + atomic_set(0, &players_ready);
>>>
>>> printf("Running with: players_per_team=%d game_length=%d\n",
>>> players_per_team, game_length);
>>> @@ -181,13 +176,20 @@
>>> param.sched_priority = sched_get_priority_min(SCHED_FIFO) + 80;
>>> sched_setscheduler(0, SCHED_FIFO, ¶m);
>>>
>>> - /* Start the offense */
>>> + /*
>>> + * Start the offense
>>> + * They are lower priority than defense, so they must be started
>>> first.
>>> + */
>>> priority = 15;
>>> printf("Starting %d offense threads at priority %d\n",
>>> players_per_team, priority);
>>> for (i = 0; i < players_per_team; i++)
>>> create_fifo_thread(thread_offense, NULL, priority);
>>>
>>> + /* Wait for the offense threads to start */
>>> + while (atomic_get(&players_ready) < players_per_team)
>>> + usleep(100);
>>> +
>>> /* Start the defense */
>>> priority = 30;
>>> printf("Starting %d defense threads at priority %d\n",
>>> @@ -195,6 +197,10 @@
>>> for (i = 0; i < players_per_team; i++)
>>> create_fifo_thread(thread_defense, NULL, priority);
>>>
>>> + /* Wait for the defense threads to start */
>>> + while (atomic_get(&players_ready) < players_per_team * 2)
>>> + usleep(100);
>>> +
>>> /* Ok, everyone is on the field, bring out the ref */
>>> printf("Starting referee thread\n");
>>> return referee(game_length);
>
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next prev parent reply other threads:[~2009-06-25 20:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-24 18:53 [LTP] [PATCH][real-time] sched_footbal atomic start Darren Hart
2009-06-25 4:16 ` gowrishankar
2009-06-25 9:10 ` Subrata Modak
2009-06-25 20:34 ` Darren Hart [this message]
2009-06-26 11:33 ` Subrata Modak
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=4A43DF48.3070808@us.ibm.com \
--to=dvhltc@us.ibm.com \
--cc=gowrishankar.m@linux.vnet.ibm.com \
--cc=ltp-list@lists.sourceforge.net \
--cc=subrata@linux.vnet.ibm.com \
/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