From: "Jeff V. Merkey" <jmerkey@utah-nac.org>
To: Carlos Antunes <cmantunes@gmail.com>
Cc: linux-kernel@vger.kernel.org, Esben Nielsen <simlo@phys.au.dk>
Subject: Re: Realtime-preempt performs worse for many threads?
Date: Tue, 01 Nov 2005 16:09:06 -0700 [thread overview]
Message-ID: <4367F592.60702@utah-nac.org> (raw)
In-Reply-To: <cb2ad8b50511011629g3e5c4b41t82c1763b029acae2@mail.gmail.com>
Oink Oink. Verified.
Jeff
Carlos Antunes wrote:
>On 11/1/05, Carlos Antunes <cmantunes@gmail.com> wrote:
>
>
>>On 11/1/05, Esben Nielsen <simlo@phys.au.dk> wrote:
>>
>>
>>>On Tue, 1 Nov 2005, Carlos Antunes wrote:
>>>
>>>
>>>
>>>>Hi!
>>>>
>>>>I've been developing some code for the OpenPBX project
>>>>(http://www.openpbx.org) and wrote a program to test how the system,
>>>>responds when hundreds of threads are spawned. These threads run at
>>>>high priority (SCHED_FIFO) and use clock_nanocleep with absolute
>>>>timeouts on a 20ms loop cycle.
>>>>
>>>>With the stock 2.6.14 kernel, I get latencies in the order of several
>>>>milliseconds (but less than 20ms) when running 1250 threads
>>>>simultaneously. However, when I switch to a kernel patched with
>>>>realtime-preempt latency increases to several hundred milliseconds in
>>>>many cases.
>>>>
>>>>
>>>There is only one explanation:
>>>Some of the operations (task switch, nanosleep etc.) are more expensive in
>>>the RT kernel. Thus your 1250 threads spend 100% CPU doing what they do.
>>>You therefore get very bad latencies.
>>>
>>>
>>>
>>Esben,
>>
>>Thanks for replying. Let me chalenge this assumption of yours, though.
>>
>>I just ran a test with those 1250 threads (all they do is sleep for
>>20ms, wake up, increment a number, and repeat the process). The CPU
>>was 86% *IDLE* while running this. One thread took 1.3 seconds to wake
>>up once. Do you think this is, well, normal, given how RT is supposed
>>to operate?
>>
>>
>>
>
>Esben,
>
>If, instead of SCHD_FIFO, I use SCHED_OTHER, I get max latency in the
>order 13ms running those 1250 threads. With SCHED_FIFO (the only
>change), I get 1.3 seconds. Makes sense to you?
>
>Thanks!
>
>Carlos
>
>--
>"We hold [...] that all men are created equal; that they are
>endowed [...] with certain inalienable rights; that among
>these are life, liberty, and the pursuit of happiness"
> -- Thomas Jefferson
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
next prev parent reply other threads:[~2005-11-02 0:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-01 20:02 Realtime-preempt performs worse for many threads? Carlos Antunes
2005-11-01 23:27 ` Esben Nielsen
[not found] ` <cb2ad8b50511011553x57ff9e4dv7f49875cf8a5d7e0@mail.gmail.com>
2005-11-02 0:29 ` Carlos Antunes
2005-11-01 23:09 ` Jeff V. Merkey [this message]
2005-11-02 0:32 ` Esben Nielsen
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=4367F592.60702@utah-nac.org \
--to=jmerkey@utah-nac.org \
--cc=cmantunes@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=simlo@phys.au.dk \
/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.