From: Anton Blanchard <anton@linuxcare.com.au>
To: Matthew Kirkwood <matthew@hairy.beasts.org>
Cc: Jonathan Lahr <lahr@sequent.com>, linux-kernel@vger.kernel.org
Subject: Re: kernel lock contention and scalability
Date: Sun, 11 Mar 2001 17:50:22 +1100 [thread overview]
Message-ID: <20010311175022.E1951@linuxcare.com> (raw)
In-Reply-To: <20010306144552.G6451@w-lahr.des.sequent.com> <Pine.LNX.4.10.10103062318190.26554-100000@sphinx.mythic-beasts.com>
In-Reply-To: <Pine.LNX.4.10.10103062318190.26554-100000@sphinx.mythic-beasts.com>; from matthew@hairy.beasts.org on Tue, Mar 06, 2001 at 11:39:17PM +0000
Hi,
> In the slow path of a spinlock_acquire they busy wait for a few
> cycles, and then call schedule with a zero timeout assuming that
> it'll basically do the same as a sched_yield() but more portably.
The obvious problem with this is that we bounce in and out of schedule()
a few times before moving on to the next task. I see this also with
sched_yield().
I had this patch lying around which I think came about when I was playing
with pthreads (which for spinlocks does sched_yield() for a while before
sleeping)
--- linux/kernel/sched.c Fri Mar 9 10:26:56 2001
+++ linux_intel/kernel/sched.c Fri Mar 9 08:42:39 2001
@@ -505,6 +505,9 @@
goto out_unlock;
}
#else
+ if (prev->policy & SCHED_YIELD)
+ prev->counter = (prev->counter >> 4);
+
prev->policy &= ~SCHED_YIELD;
#endif /* CONFIG_SMP */
}
Anton
/* test sched_yield */
#include <stdio.h>
#include <sched.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
#undef USE_SELECT
void waste_time()
{
int i;
for(i = 0; i < 10000; i++)
;
}
void do_stuff(int i)
{
#ifdef USE_SELECT
struct timeval tv;
#endif
while(1) {
fprintf(stderr, "%d\n", i);
waste_time();
#ifdef USE_SELECT
tv.tv_sec = 0;
tv.tv_usec = 0;
select(0, NULL, NULL, NULL, &tv);
#else
sched_yield();
#endif
}
}
int main()
{
int i, pid;
for(i = 0; i < 10; i++) {
pid = fork();
if (!pid)
do_stuff(i);
}
do_stuff(i+1);
return 0;
}
next prev parent reply other threads:[~2001-03-11 6:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-15 18:46 kernel lock contention and scalability Jonathan Lahr
2001-02-25 9:52 ` Manfred Spraul
2001-03-05 18:41 ` Jonathan Lahr
2001-03-05 0:38 ` Anton Blanchard
2001-03-06 22:45 ` Jonathan Lahr
2001-03-06 23:39 ` Matthew Kirkwood
2001-03-07 0:28 ` Tim Wright
2001-03-07 3:12 ` Jeff Dike
2001-03-07 22:13 ` Tim Wright
2001-03-08 23:26 ` Jeff Dike
2001-03-11 6:50 ` Anton Blanchard [this message]
2001-03-11 6:26 ` Anton Blanchard
[not found] <98454d$19p9h$1@fido.engr.sgi.com>
2001-03-07 2:55 ` Rajagopal Ananthanarayanan
2001-03-07 5:48 ` Jeff Dike
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=20010311175022.E1951@linuxcare.com \
--to=anton@linuxcare.com.au \
--cc=lahr@sequent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@hairy.beasts.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.