* real-time priority
@ 2009-03-19 22:45 Rodrigo Amestica
2009-03-19 23:11 ` Rodrigo Amestica
2009-03-19 23:13 ` Frank Rowand
0 siblings, 2 replies; 4+ messages in thread
From: Rodrigo Amestica @ 2009-03-19 22:45 UTC (permalink / raw)
To: linux-rt-users
Hi,
general questions from somebody who's just starting to look into the
preempt patch.
the article linked below makes direct reference to the behavior of the
preempt rt patch. The article was written in 2007. How much of that
still holds true in the current version of the patch?
I'm basically wondering about the first sentences in the abstract of
that article. The big picture seems to be rather simple: calls to
specific linux services could break the performance of a real time task
by depending on lower priority tasks to complete that service.
Does this mean that one must always be alert to which system services
are invoked during the execution of a real time task? Does the vanilla
kernel or the preempt-rt patch tries to somehow detect this condition
and alert somehow?
thanks,
Rodrigo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: real-time priority
2009-03-19 22:45 real-time priority Rodrigo Amestica
@ 2009-03-19 23:11 ` Rodrigo Amestica
2009-03-19 23:26 ` Frank Rowand
2009-03-19 23:13 ` Frank Rowand
1 sibling, 1 reply; 4+ messages in thread
From: Rodrigo Amestica @ 2009-03-19 23:11 UTC (permalink / raw)
To: linux-rt-users
yes, i forgot to include the link. now it goes.
http://www.ddj.com/linux-open-source/200900827
Rodrigo Amestica wrote:
> Hi,
>
> general questions from somebody who's just starting to look into the
> preempt patch.
>
> the article linked below makes direct reference to the behavior of the
> preempt rt patch. The article was written in 2007. How much of that
> still holds true in the current version of the patch?
>
> I'm basically wondering about the first sentences in the abstract of
> that article. The big picture seems to be rather simple: calls to
> specific linux services could break the performance of a real time
> task by depending on lower priority tasks to complete that service.
>
> Does this mean that one must always be alert to which system services
> are invoked during the execution of a real time task? Does the vanilla
> kernel or the preempt-rt patch tries to somehow detect this condition
> and alert somehow?
>
> thanks,
> Rodrigo
>
> --
> 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
>
> ____________________________________________________________________________________
>
> Click here to find the perfect banking opportunity!
> http://ads.lavabit.com/fc/BLSrjwrz8JR8QtO2thrVR65MkKPO7Tm4zsO0sj7xJYVXikFfIocXosXcLFO/
>
> ____________________________________________________________________________________
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: real-time priority
2009-03-19 22:45 real-time priority Rodrigo Amestica
2009-03-19 23:11 ` Rodrigo Amestica
@ 2009-03-19 23:13 ` Frank Rowand
1 sibling, 0 replies; 4+ messages in thread
From: Frank Rowand @ 2009-03-19 23:13 UTC (permalink / raw)
To: Rodrigo Amestica; +Cc: linux-rt-users
Rodrigo Amestica wrote:
> Hi,
>
> general questions from somebody who's just starting to look into the
> preempt patch.
>
> the article linked below makes direct reference to the behavior of the
The link is missing.
> preempt rt patch. The article was written in 2007. How much of that
> still holds true in the current version of the patch?
>
> I'm basically wondering about the first sentences in the abstract of
> that article. The big picture seems to be rather simple: calls to
> specific linux services could break the performance of a real time task
> by depending on lower priority tasks to complete that service.
>
> Does this mean that one must always be alert to which system services
> are invoked during the execution of a real time task? Does the vanilla
> kernel or the preempt-rt patch tries to somehow detect this condition
> and alert somehow?
>
> thanks,
> Rodrigo
>
> --
> 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
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: real-time priority
2009-03-19 23:11 ` Rodrigo Amestica
@ 2009-03-19 23:26 ` Frank Rowand
0 siblings, 0 replies; 4+ messages in thread
From: Frank Rowand @ 2009-03-19 23:26 UTC (permalink / raw)
To: Rodrigo Amestica; +Cc: linux-rt-users
Rodrigo Amestica wrote:
> yes, i forgot to include the link. now it goes.
>
> http://www.ddj.com/linux-open-source/200900827
>
> Rodrigo Amestica wrote:
>> Hi,
>>
>> general questions from somebody who's just starting to look into the
>> preempt patch.
>>
>> the article linked below makes direct reference to the behavior of the
>> preempt rt patch. The article was written in 2007. How much of that
>> still holds true in the current version of the patch?
>>
>> I'm basically wondering about the first sentences in the abstract of
>> that article. The big picture seems to be rather simple: calls to
>> specific linux services could break the performance of a real time
>> task by depending on lower priority tasks to complete that service.
>>
>> Does this mean that one must always be alert to which system services
>> are invoked during the execution of a real time task?
Yes.
>> Does the vanilla
>> kernel or the preempt-rt patch tries to somehow detect this condition
>> and alert somehow?
I am not aware of any such test, but it sounds like an interesting idea.
>>
>> thanks,
>> Rodrigo
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-03-19 23:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-19 22:45 real-time priority Rodrigo Amestica
2009-03-19 23:11 ` Rodrigo Amestica
2009-03-19 23:26 ` Frank Rowand
2009-03-19 23:13 ` Frank Rowand
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.