All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhltc@us.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: ltp-list <ltp-list@lists.sf.net>,
	Gregory Haskins <ghaskins@novell.com>,
	Clark Williams <clark.williams@gmail.com>,
	linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: [LTP] LTP RT Tests (Cyclic, rt-migrate, etc)
Date: Mon, 20 Jul 2009 10:03:37 -0700	[thread overview]
Message-ID: <4A64A369.8040808@us.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0907201039140.3858@gandalf.stny.rr.com>

Steven Rostedt wrote:
> On Fri, 10 Jul 2009, Darren Hart wrote:
> 
>> Subrata Modak wrote:
>>> On Fri, 2009-07-10 at 22:00 +0530, Sripathi Kodi wrote:
>>>> On Wednesday 08 July 2009 23:43:53 Subrata Modak wrote:
>>>>> Darren/Sri/Gowri,
>>>>>
>>>>> Where do you want me to put this exactly inside the RT tree ?
>>>> Hi Subrata,
>>>>
>>>> Going by how the tests are organized currently, I think this should go
>>>> into it's own directory under testcases/realtime/func. We will need to
>>>> add a makefile to it. Are you looking at us to help you with this?
>>> Correct. Please send me a patch which integrates it into RT tests build,
>>> install & run.
>> Just got back from a week vacation and am burning through mail as fast as I
>> can :-) Haven't had a look yet, but does this test use librttest.h?  I suspect
>> not.  We'll need to adapt it to run within the existing ltp real-time testing
>> framework, which includes things like buffered output as well as mlocking
>> support.
>>
>> Lastly, I'm not sure this test does anything effectively different than
>> prio-wake, already in the tree.  My other concerns with the test are its
>> explicit 1ms preemption criteria (as Steven described it anyway).  We are
>> trying to move away from criteria being inherent in measurement tests, and 1
>> ms seems like an awfully long priority inversion to be an acceptable criteria
>> to many users.
>>
>> Steven, am I missing something conceptually here?
> 
> Hmm, I missed this email, sorry for the late reply.
> 
> What does prio-wake do?
> 
> This test is what I used to develop the rt scheduler in mainline (as well 
> as in -rt).  It wakes up N+1 tasks with lowering real time priorities. 
> Where N is the number of CPUs in the system. Then it makes sure that the 
> these tasks spread out across the CPUs. Most tests just test the highest 
> priority task in the system. But those tests usually miss the second 
> highest prio task in the system. If you have a second highest prio task in 
> the system and a CPU is available to run, then it should run on that CPU. 
> But what happens is that it can wait to be migrated and can take millisecs 
> to wake up.
> 
> This test makes sure that all the high prio tasks that are in the running 
> state are actually running on a CPU if it can.
> 
> Make sense?

Yup.  This is different than prio-wake.  Prio-wake creates some number 
of threads of varying priorities and puts them to sleep on 
pthread_cond_wait and then wakes them with pthread_cond_broadcast, then 
tests that the threads were woken in priority order.  Fails on 
kernels/glibc without requeue pi support as a FUTEX_WAKE(all) was used 
for PI mutexes.

So to include this in the ltp/restcases/realtime suite, the test should 
make use of the librttest.c and libstats.c apis, standardized argument 
parsing, buffered logging mechanism, and standardized output formatting. 
  I can't get to that for a little while myself, but can assist if you 
have any questions.  Alternatively we can wait a little while, and 
perhaps someone on my team will be able to help merge it with the 
realtime test infrastructure in LTP.

> 
> (BTW, current -rt and mainline now fail this test :-? )

Hrm, uh oh.  Adding it to my lengthy list of things to try and look at :/

Thanks Steve,

-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

WARNING: multiple messages have this Message-ID (diff)
From: Darren Hart <dvhltc@us.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: subrata@linux.vnet.ibm.com, Sripathi Kodi <sripathik@in.ibm.com>,
	Gowrishankar <gomuthuk@linux.vnet.ibm.com>,
	ltp-list <ltp-list@lists.sf.net>,
	linux-rt-users <linux-rt-users@vger.kernel.org>,
	Gregory Haskins <ghaskins@novell.com>,
	Clark Williams <clark.williams@gmail.com>
Subject: Re: [LTP] LTP RT Tests (Cyclic, rt-migrate, etc)
Date: Mon, 20 Jul 2009 10:03:37 -0700	[thread overview]
Message-ID: <4A64A369.8040808@us.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0907201039140.3858@gandalf.stny.rr.com>

Steven Rostedt wrote:
> On Fri, 10 Jul 2009, Darren Hart wrote:
> 
>> Subrata Modak wrote:
>>> On Fri, 2009-07-10 at 22:00 +0530, Sripathi Kodi wrote:
>>>> On Wednesday 08 July 2009 23:43:53 Subrata Modak wrote:
>>>>> Darren/Sri/Gowri,
>>>>>
>>>>> Where do you want me to put this exactly inside the RT tree ?
>>>> Hi Subrata,
>>>>
>>>> Going by how the tests are organized currently, I think this should go
>>>> into it's own directory under testcases/realtime/func. We will need to
>>>> add a makefile to it. Are you looking at us to help you with this?
>>> Correct. Please send me a patch which integrates it into RT tests build,
>>> install & run.
>> Just got back from a week vacation and am burning through mail as fast as I
>> can :-) Haven't had a look yet, but does this test use librttest.h?  I suspect
>> not.  We'll need to adapt it to run within the existing ltp real-time testing
>> framework, which includes things like buffered output as well as mlocking
>> support.
>>
>> Lastly, I'm not sure this test does anything effectively different than
>> prio-wake, already in the tree.  My other concerns with the test are its
>> explicit 1ms preemption criteria (as Steven described it anyway).  We are
>> trying to move away from criteria being inherent in measurement tests, and 1
>> ms seems like an awfully long priority inversion to be an acceptable criteria
>> to many users.
>>
>> Steven, am I missing something conceptually here?
> 
> Hmm, I missed this email, sorry for the late reply.
> 
> What does prio-wake do?
> 
> This test is what I used to develop the rt scheduler in mainline (as well 
> as in -rt).  It wakes up N+1 tasks with lowering real time priorities. 
> Where N is the number of CPUs in the system. Then it makes sure that the 
> these tasks spread out across the CPUs. Most tests just test the highest 
> priority task in the system. But those tests usually miss the second 
> highest prio task in the system. If you have a second highest prio task in 
> the system and a CPU is available to run, then it should run on that CPU. 
> But what happens is that it can wait to be migrated and can take millisecs 
> to wake up.
> 
> This test makes sure that all the high prio tasks that are in the running 
> state are actually running on a CPU if it can.
> 
> Make sense?

Yup.  This is different than prio-wake.  Prio-wake creates some number 
of threads of varying priorities and puts them to sleep on 
pthread_cond_wait and then wakes them with pthread_cond_broadcast, then 
tests that the threads were woken in priority order.  Fails on 
kernels/glibc without requeue pi support as a FUTEX_WAKE(all) was used 
for PI mutexes.

So to include this in the ltp/restcases/realtime suite, the test should 
make use of the librttest.c and libstats.c apis, standardized argument 
parsing, buffered logging mechanism, and standardized output formatting. 
  I can't get to that for a little while myself, but can assist if you 
have any questions.  Alternatively we can wait a little while, and 
perhaps someone on my team will be able to help merge it with the 
realtime test infrastructure in LTP.

> 
> (BTW, current -rt and mainline now fail this test :-? )

Hrm, uh oh.  Adding it to my lengthy list of things to try and look at :/

Thanks Steve,

-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

  parent reply	other threads:[~2009-07-20 17:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1224509719.5152.116.camel@subratamodak.linux.ibm.com>
     [not found] ` <1224840077.5270.69.camel@subratamodak.linux.ibm.com>
     [not found]   ` <alpine.DEB.1.10.0810240749470.25677@gandalf.stny.rr.com>
     [not found]     ` <1229093480.5171.60.camel@subratamodak.linux.ibm.com>
     [not found]       ` <alpine.DEB.1.10.0812121533350.29763@gandalf.stny.rr.com>
     [not found]         ` <1229347938.5353.8.camel@subratamodak.linux.ibm.com>
     [not found]           ` <alpine.DEB.1.10.0812150851290.18692@gandalf.stny.rr.com>
     [not found]             ` <1245768486.4860.53.camel@subratamodak.linux.ibm.com>
2009-07-06 14:26               ` [LTP] LTP RT Tests (Cyclic, rt-migrate, etc) Steven Rostedt
2009-07-06 14:31                 ` Subrata Modak
2009-07-06 14:31                   ` Subrata Modak
2009-07-08 18:13                   ` Subrata Modak
2009-07-08 18:13                     ` Subrata Modak
2009-07-10 16:30                     ` Sripathi Kodi
2009-07-10 16:30                       ` Sripathi Kodi
2009-07-10 16:47                       ` Subrata Modak
2009-07-10 16:47                         ` Subrata Modak
2009-07-10 18:28                         ` Darren Hart
2009-07-10 18:28                           ` Darren Hart
2009-07-20 14:43                           ` Steven Rostedt
2009-07-20 14:43                             ` Steven Rostedt
2009-07-20 14:52                             ` Gregory Haskins
2009-07-20 14:52                               ` Gregory Haskins
2009-07-20 17:03                             ` Darren Hart [this message]
2009-07-20 17:03                               ` Darren Hart
2009-07-30 18:28                               ` Subrata Modak
2009-07-30 18:28                                 ` Subrata Modak
2009-07-30 18:42                                 ` Steven Rostedt
2009-07-30 18:42                                   ` Steven Rostedt
2009-07-30 19:49                                   ` Darren Hart
2009-07-30 19:49                                     ` Darren Hart
2009-07-30 20:03                                     ` Steven Rostedt
2009-07-30 20:03                                       ` Steven Rostedt
2009-07-30 20:10                                       ` Darren Hart
2009-07-30 20:10                                         ` Darren Hart

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=4A64A369.8040808@us.ibm.com \
    --to=dvhltc@us.ibm.com \
    --cc=clark.williams@gmail.com \
    --cc=ghaskins@novell.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=ltp-list@lists.sf.net \
    --cc=rostedt@goodmis.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.