From: Jussi Laako <jussi.laako@kolumbus.fi>
To: Mike Kravetz <kravetz@us.ibm.com>
Cc: Robert Love <rml@tech9.net>, mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: O(1) scheduler gives big boost to tbench 192
Date: Thu, 09 May 2002 03:26:24 +0300 [thread overview]
Message-ID: <3CD9C230.9989F491@kolumbus.fi> (raw)
In-Reply-To: <20020507151356.A18701@w-mikek.des.beaverton.ibm.com> <E175DhD-0000HF-00@the-village.bc.nu> <20020507154322.F1537@w-mikek2.des.beaverton.ibm.com> <1020814775.2084.43.camel@bigsur> <20020507164857.G1537@w-mikek2.des.beaverton.ibm.com> <3CD94582.DE18AB99@kolumbus.fi> <1020875500.2078.117.camel@bigsur> <20020508100224.C1531@w-mikek2.des.beaverton.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
Mike Kravetz wrote:
>
> Is there anything simple I can do to check the latencies of the
> pthread_cond_*() functions? I'd like to do some analysis of
> scheduler behavior, but am unfamiliar with the user level code.
I just wrote small test program (attached) for testing this. It is similar
to my app, but for this test the soundcard is just used more as a timing
source.
Adjust the buffer size so that it's on the edge of missing blocks then
generate some system load to run it over the edge to see how sensitive it is
and how many blocks are lost. I can see clear difference using kernel with
original scheduler and with kernel having the O(1) scheduler.
It's quite sensitive when you run it without setuid privileges, but normal
situation is to run it at SCHED_FIFO.
Because of famous ReiserFS tailmerging feature lost-and-rewrote part of it
after crashing system with it. Found the the binary overwriting top of it
after reboot... I was happy to have copied it to another machine over NFS
just a few minutes before crash, so not much was lost.
- Jussi Laako
--
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B
Available at PGP keyservers
[-- Attachment #2: schedtest.c --]
[-- Type: application/x-unknown-content-type-cfile, Size: 5022 bytes --]
next prev parent reply other threads:[~2002-05-09 0:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-03 13:38 O(1) scheduler gives big boost to tbench 192 rwhron
2002-05-03 20:29 ` Gerrit Huizenga
2002-05-04 8:13 ` Andrea Arcangeli
2002-05-07 22:13 ` Mike Kravetz
2002-05-07 22:44 ` Alan Cox
2002-05-07 22:43 ` Mike Kravetz
2002-05-07 23:39 ` Robert Love
2002-05-07 23:48 ` Mike Kravetz
2002-05-08 15:34 ` Jussi Laako
2002-05-08 16:31 ` Robert Love
2002-05-08 17:02 ` Mike Kravetz
2002-05-09 0:26 ` Jussi Laako [this message]
2002-05-08 8:50 ` Andrea Arcangeli
2002-05-09 23:18 ` Mike Kravetz
-- strict thread matches above, loose matches on Subject: below --
2002-05-20 12:46 rwhron
2002-05-08 16:39 Bill Davidsen
2002-05-06 8:20 rwhron
2002-05-06 16:42 ` Andrea Arcangeli
2002-05-03 16:37 John Hawkes
2002-05-02 21:36 rwhron
2002-05-03 0:09 ` Gerrit Huizenga
2002-05-02 23:17 ` J.A. Magallon
2002-05-03 0:14 ` Alan Cox
2002-05-03 1:08 ` Gerrit Huizenga
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=3CD9C230.9989F491@kolumbus.fi \
--to=jussi.laako@kolumbus.fi \
--cc=kravetz@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rml@tech9.net \
/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