From: Kyle Moffett <mrmacman_g4@mac.com>
To: Howard Chu <hyc@symas.com>
Cc: Helge Hafting <helge.hafting@aitel.hist.no>,
"linux-os (Dick Johnson)" <linux-os@analogic.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Lee Revell <rlrevell@joe-job.com>,
Christopher Friesen <cfriesen@nortel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
hancockr@shaw.ca
Subject: Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
Date: Mon, 30 Jan 2006 10:33:34 -0500 [thread overview]
Message-ID: <461FB690-4F18-409D-BC0A-6A3CC1F8312C@mac.com> (raw)
In-Reply-To: <43DDD359.8090000@symas.com>
On Jan 30, 2006, at 03:50, Howard Chu wrote:
> Helge Hafting wrote:
>> linux-os (Dick Johnson) wrote:
>>> To fix the current problem, you can substitute usleep(0); It will
>>> give the CPU to somebody if it's computable, then give it back to
>>> you. It seems to work in every case that sched_yield() has mucked
>>> up (perhaps 20 to 30 here).
>>
>> Isn't that dangerous? Someday, someone working on linux (or some
>> other unixish os) might come up with an usleep implementation
>> where usleep(0) just returns and becomes a no-op. Which probably
>> is ok with the usleep spec - it did sleep for zero time . . .
>
> We actually experimented with usleep(0) and select(...) with a
> zeroed timeval. Both of these approaches performed worse than just
> using sched_yield(), depending on the system and some other
> conditions. Dual-core AMD64 vs single-CPU had quite different
> behaviors. Also, if the slapd main event loop was using epoll()
> instead of select(), the select's used for yields slowed down by a
> couple orders of magnitude. (A test that normally took ~30 seconds
> took as long as 45 minutes in one case, it was quite erratic.)
>
> It turned out that most of those yield's were leftovers inherited
> from when we only supported non-preemptive threads, and simply
> deleting them was the best approach.
I would argue that in a non realtime environment sched_yield() is not
useful at all. When you want to wait for another process, you wait
explicitly for that process using one of the various POSIX-defined
methods, such as mutexes, condition variables, etc. There are very
clearly and thoroughly defined ways to wait for other processes to
complete work, why rely on usleep(0) giving CPU to some other task
when you can explicitly tell the scheduler "I am waiting for task foo
to release this mutex" or "I can't run until somebody signals this
condition variable".
Cheers,
Kyle Moffett
--
Unix was not designed to stop people from doing stupid things,
because that would also stop them from doing clever things.
-- Doug Gwyn
next prev parent reply other threads:[~2006-01-30 15:34 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-24 22:59 e100 oops on resume Stefan Seyfried
2006-01-24 23:21 ` Mattia Dongili
2006-01-25 9:02 ` Olaf Kirch
2006-01-25 12:11 ` Olaf Kirch
2006-01-25 13:51 ` sched_yield() makes OpenLDAP slow Howard Chu
2006-01-25 14:38 ` Robert Hancock
2006-01-25 17:49 ` Christopher Friesen
2006-01-25 18:26 ` pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) Howard Chu
2006-01-25 18:59 ` Nick Piggin
2006-01-25 19:32 ` Howard Chu
2006-01-26 8:51 ` Nick Piggin
2006-01-26 14:15 ` Kyle Moffett
2006-01-26 14:43 ` Howard Chu
2006-01-26 19:57 ` David Schwartz
2006-01-26 20:27 ` Howard Chu
2006-01-26 20:46 ` Nick Piggin
2006-01-26 21:32 ` Howard Chu
2006-01-26 21:41 ` Nick Piggin
2006-01-26 21:56 ` Howard Chu
2006-01-26 22:24 ` Nick Piggin
2006-01-27 8:08 ` Howard Chu
2006-01-27 19:25 ` Philipp Matthias Hahn
2006-02-01 12:31 ` Nick Piggin
2006-01-27 4:27 ` Steven Rostedt
2006-01-26 21:58 ` Christopher Friesen
2006-01-27 4:13 ` Steven Rostedt
2006-01-27 2:16 ` David Schwartz
2006-01-27 8:19 ` Howard Chu
2006-01-27 19:50 ` David Schwartz
2006-01-27 20:13 ` Howard Chu
2006-01-27 21:05 ` David Schwartz
2006-01-27 21:23 ` Howard Chu
2006-01-27 23:31 ` David Schwartz
2006-01-30 8:28 ` Helge Hafting
2006-01-26 10:38 ` Nikita Danilov
2006-01-30 8:35 ` Helge Hafting
2006-01-30 11:13 ` Nikita Danilov
2006-01-31 23:18 ` David Schwartz
2006-01-25 21:06 ` Lee Revell
2006-01-25 22:14 ` Howard Chu
2006-01-26 0:16 ` Robert Hancock
2006-01-26 0:49 ` Howard Chu
2006-01-26 1:04 ` Lee Revell
2006-01-26 1:31 ` Howard Chu
2006-01-26 2:05 ` David Schwartz
2006-01-26 2:48 ` Mark Lord
2006-01-26 3:30 ` David Schwartz
2006-01-26 3:49 ` Samuel Masham
2006-01-26 4:02 ` Samuel Masham
2006-01-26 4:53 ` Lee Revell
2006-01-26 6:14 ` Samuel Masham
2006-01-26 8:54 ` Nick Piggin
2006-01-26 14:24 ` Howard Chu
2006-01-26 14:54 ` Nick Piggin
2006-01-26 15:23 ` Howard Chu
2006-01-26 15:51 ` Nick Piggin
2006-01-26 16:44 ` Howard Chu
2006-01-26 17:34 ` linux-os (Dick Johnson)
2006-01-26 19:00 ` Nick Piggin
2006-01-26 19:14 ` linux-os (Dick Johnson)
2006-01-26 21:12 ` Nick Piggin
2006-01-26 21:31 ` linux-os (Dick Johnson)
2006-01-27 7:06 ` Valdis.Kletnieks
2006-01-30 8:44 ` Helge Hafting
2006-01-30 8:50 ` Howard Chu
2006-01-30 15:33 ` Kyle Moffett [this message]
2006-01-30 13:28 ` linux-os (Dick Johnson)
2006-01-30 15:15 ` Helge Hafting
2006-01-26 10:44 ` Nikita Danilov
2006-01-26 0:08 ` Robert Hancock
2006-01-26 1:07 ` sched_yield() makes OpenLDAP slow David Schwartz
2006-01-26 8:30 ` Helge Hafting
2006-01-26 9:01 ` Nick Piggin
2006-01-26 10:50 ` Nikita Danilov
2006-01-25 19:37 ` e100 oops on resume Jesse Brandeburg
2006-01-25 20:14 ` Olaf Kirch
2006-01-25 22:28 ` Jesse Brandeburg
2006-01-26 0:28 ` Jesse Brandeburg
2006-01-26 9:32 ` Pavel Machek
2006-01-26 19:02 ` Stefan Seyfried
2006-01-26 19:09 ` Olaf Kirch
2006-01-28 11:53 ` Mattia Dongili
2006-01-28 19:53 ` Jesse Brandeburg
2006-02-07 6:57 ` Jeff Garzik
[not found] ` <BAY108-DAV111F6EF46F6682FEECCC1593140@phx.gbl>
[not found] ` <4807377b0601271404w6dbfcff6s4de1c3f785dded9f@mail.gmail.com>
2006-01-30 17:25 ` Can I do a regular read to simulate prefetch instruction? John Smith
2006-01-30 22:01 pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) linux
2006-01-30 23:37 linux
2006-02-01 17:06 Lee Schermerhorn
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=461FB690-4F18-409D-BC0A-6A3CC1F8312C@mac.com \
--to=mrmacman_g4@mac.com \
--cc=cfriesen@nortel.com \
--cc=hancockr@shaw.ca \
--cc=helge.hafting@aitel.hist.no \
--cc=hyc@symas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
--cc=nickpiggin@yahoo.com.au \
--cc=rlrevell@joe-job.com \
/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
all inboxes | Powered by JetHome®