All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Haskins <ghaskins@novell.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: ltp-list <ltp-list@lists.sf.net>,
	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:52:32 -0400	[thread overview]
Message-ID: <4A6484B0.3050009@novell.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0907201039140.3858@gandalf.stny.rr.com>


[-- Attachment #1.1: Type: text/plain, Size: 3454 bytes --]

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.

Just to add to Steven's comments below:  At the time that rt-migrate was
written, LTP and others lacked sufficient resolution in their testing to
reliably find the type of problem that rt-migratate can pinpoint
quickly.  IIRC, "football" was potentially capable of finding these
types of scheduler bugs, but it often failed to find it at all, or it
took 24h+ of runtime to find it.  Steven's test could find it in under a
second or two.  And, as Steven mentions below, rt-migrate is
additionally designed to look at the top N prio tasks (where N = cpu-count)

That said, I am not familiar with "prio-wake" so I am not sure if its
new or if it has direct overlap with Steven's test or not.

>>   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?
>
> (BTW, current -rt and mainline now fail this test :-? )
>
> -- Steve
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

[-- Attachment #2: Type: text/plain, Size: 389 bytes --]

------------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
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: Gregory Haskins <ghaskins@novell.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Darren Hart <dvhltc@us.ibm.com>,
	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>,
	Clark Williams <clark.williams@gmail.com>
Subject: Re: [LTP] LTP RT Tests (Cyclic, rt-migrate, etc)
Date: Mon, 20 Jul 2009 10:52:32 -0400	[thread overview]
Message-ID: <4A6484B0.3050009@novell.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0907201039140.3858@gandalf.stny.rr.com>

[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]

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.

Just to add to Steven's comments below:  At the time that rt-migrate was
written, LTP and others lacked sufficient resolution in their testing to
reliably find the type of problem that rt-migratate can pinpoint
quickly.  IIRC, "football" was potentially capable of finding these
types of scheduler bugs, but it often failed to find it at all, or it
took 24h+ of runtime to find it.  Steven's test could find it in under a
second or two.  And, as Steven mentions below, rt-migrate is
additionally designed to look at the top N prio tasks (where N = cpu-count)

That said, I am not familiar with "prio-wake" so I am not sure if its
new or if it has direct overlap with Steven's test or not.

>>   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?
>
> (BTW, current -rt and mainline now fail this test :-? )
>
> -- Steve
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

  reply	other threads:[~2009-07-20 14:52 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 [this message]
2009-07-20 14:52                               ` Gregory Haskins
2009-07-20 17:03                             ` Darren Hart
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=4A6484B0.3050009@novell.com \
    --to=ghaskins@novell.com \
    --cc=clark.williams@gmail.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.