From: kumon@flab.fujitsu.co.jp
To: linux-kernel@vger.kernel.org
Cc: andrewm@uow.edu.au, dean-list-linux-kernel@arctic.org
Cc: viro@math.psu.edu
Cc: kumon@flab.fujitsu.co.jp
Subject: Preemptive scheduling of woken-up processes
Date: Sat, 4 Nov 2000 14:55:30 +0900 [thread overview]
Message-ID: <200011040555.OAA02581@asami.proc.flab.fujitsu.co.jp> (raw)
In-Reply-To: <Pine.GSO.4.21.0010270257550.18660-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0010270257550.18660-100000@weyl.math.psu.edu>
The current schduler has a problem handling waken up processes.
In the current kernel woken up processes probably try to preempt CPU
from the currently running process.
That is the fundamental reason of the negative scalability of Apache
on a large SMP system, which has been reported already.
The modification of scheduler is introduced between test8 and test9.
So, test9 owes two problems for the Apache performance.
One for flock, another for scheduler.
Detailed Description:
When a process releases the semaphore, it wakes up the slept process
through wake_up_process(). Then, schedule_idle() has the final duty.
In the current scheduler logic, the woken up process may preempt CPU
from the current process if the goodness tells to do so. This is done
even if there are lots of idle CPUs. This severy disables parallel
execution on a MP system. The previously runnning process is runnable
but wating on run queue until the next scheduling timing, which
possibly is few milliseconds later.
# We've not yet proved above senario by experimentation. We'll do in
# next week if it is needed.
I think this scheduling policy is bad for MP systems.
Basically, the waken up process should run on the previous CPU ,
or, should run on an idle CPU.
This policy has been adopted in test8, and that is better, I think.
# Sorry to whom get this mail twice. I mistook LK-ML address.
--
Computer Systems Laboratory, Fujitsu Labs.
kumon@flab.fujitsu.co.jp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-04 5:55 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200010261405.XAA19135@asami.proc.flab.fujitsu.co.jp>
[not found] ` <200010250736.QAA12373@asami.proc.flab.fujitsu.co.jp>
[not found] ` <Pine.LNX.4.21.0010251242050.943-100000@duckman.distro.conectiva>
[not found] ` <200010260138.KAA17028@asami.proc.flab.fujitsu.co.jp>
2000-10-27 6:24 ` Negative scalability by removal of lock_kernel()? (Was: Strange performance behavior of 2.4.0-test9) kumon
2000-10-27 6:32 ` Negative scalability by removal of lock_kernel()?(Was: " Jeff V. Merkey
2000-10-27 7:13 ` Alexander Viro
2000-10-27 7:46 ` Andi Kleen
2000-10-27 10:23 ` Andrew Morton
2000-10-27 10:25 ` Andi Kleen
2000-10-27 12:57 ` [PATCH] " kumon
2000-10-28 15:46 ` Andrew Morton
2000-10-28 15:58 ` Andi Kleen
2000-10-28 16:05 ` Jeff Garzik
2000-10-28 16:20 ` [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was: Alan Cox
2000-10-29 19:45 ` dean gaudet
2000-10-30 6:29 ` Andi Kleen
2000-10-30 15:28 ` Andrea Arcangeli
2000-10-30 16:36 ` Rik van Riel
2000-10-30 18:02 ` Andrea Arcangeli
2000-10-28 16:46 ` [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9) Andrew Morton
2000-10-30 9:27 ` kumon
2000-10-30 15:00 ` Andrew Morton
2000-10-30 23:24 ` dean gaudet
2000-11-04 5:08 ` [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange " Andrew Morton
2000-11-04 6:23 ` Linus Torvalds
2000-11-04 10:54 ` [PATCH] Re: Negative scalability by removal of Alan Cox
2000-11-04 17:22 ` Linus Torvalds
2000-11-05 16:22 ` Andrea Arcangeli
2000-11-05 20:21 ` dean gaudet
2000-11-05 22:43 ` Alan Cox
2000-11-04 20:03 ` [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange performance behavior of 2.4.0-test9) dean gaudet
2000-11-04 20:42 ` [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange Alan Cox
2000-11-04 20:11 ` [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange performance behavior of 2.4.0-test9) dean gaudet
2000-11-04 20:43 ` [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange Alan Cox
2000-11-05 4:52 ` dean gaudet
2000-10-31 15:36 ` [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9) Andrew Morton
2000-11-02 12:50 ` kumon
2000-11-01 1:02 ` kumon
2000-11-02 11:09 ` kumon
2000-11-04 5:07 ` Andrew Morton
2000-10-27 8:17 ` Jeff V. Merkey
2000-11-04 5:55 ` kumon [this message]
2000-10-27 10:11 ` kumon
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=200011040555.OAA02581@asami.proc.flab.fujitsu.co.jp \
--to=kumon@flab.fujitsu.co.jp \
--cc=andrewm@uow.edu.au \
--cc=dean-list-linux-kernel@arctic.org \
--cc=linux-kernel@vger.kernel.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 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®