From: Rick Lindsley <ricklind@us.ibm.com>
To: Timothy Miller <miller@techsource.com>
Cc: Mike Fedyk <mfedyk@matchmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Use of AI for process scheduling
Date: Mon, 08 Sep 2003 18:19:28 -0700 [thread overview]
Message-ID: <200309090119.h891JS307266@owlet.beaverton.ibm.com> (raw)
In-Reply-To: Your message of "Mon, 08 Sep 2003 20:06:04 EDT." <3F5D196C.2040202@techsource.com>
Yeah, I didn't think his comment was very helpful since I thought it was
clear that I was working on a draft of an IDEA.
How complex is your thinking where *ideas* need drafts? :)
A scheduler which modifies behavior based on its load is not unreasonable,
but it doesn't need a neural net to do so. We just have to tell
it what's important. To do that, WE have to know what's important.
And we haven't figured that all out yet.
For example, just-completed I/O by xmms, even though xmms performs
lots of I/O, is important, but just-completed I/O by the db app, which
also performs lots of I/O, is not. Well, unless you're on the server
instead of the laptop; then the db app is important. Does there exist
sufficient context about the two types of processes that we, the human,
can make a decision? Everything I've seen so far is just "well, that's
just what *I* want in that situation." If so, we'll never get that right
even with a neural net.
However, once we characterize "what we want" we might be able to
communicate it (and code it) to the kernel. To that end, here's an
update on scheduler statistics code. In testing, it's proved fairly
non-intrusive and may provide some answers to "what we want". If it
doesn't, it's fairly extensible if done carefully.
http://eaglet.rain.com/rick/linux/schedstat/
This patch (against 2.6.0-test4 or 2.6.0-test5) collects data about
scheduler decisions, which may allow us, with 20/20 hindsight, to
determine which specific decisions we don't like and perhaps how to
modify them.
Rick
next prev parent reply other threads:[~2003-09-09 1:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-08 19:28 Timothy Miller
2003-09-08 21:55 ` Jeff Sipek
2003-09-08 22:56 ` Timothy Miller
2003-09-08 22:28 ` Felipe Alfaro Solana
2003-09-08 23:01 ` Timothy Miller
2003-09-08 23:57 ` David Lang
2003-09-09 0:34 ` Timothy Miller
2003-09-09 1:40 ` Robin Rosenberg
2003-09-09 1:57 ` Robin Rosenberg
2003-09-09 15:16 ` Timothy Miller
2003-09-09 15:14 ` Robin Rosenberg
2003-09-08 22:57 ` William Lee Irwin III
2003-09-08 23:06 ` Mike Fedyk
2003-09-08 23:14 ` William Lee Irwin III
2003-09-09 0:22 ` Timothy Miller
2003-09-09 1:05 ` William Lee Irwin III
2003-09-09 15:08 ` Timothy Miller
2003-09-09 17:47 ` William Lee Irwin III
2003-09-09 0:06 ` Timothy Miller
2003-09-09 1:19 ` Rick Lindsley [this message]
2003-09-09 15:11 ` Timothy Miller
-- strict thread matches above, loose matches on Subject: below --
2003-09-09 19:05 John Yau
2003-09-08 18:57 Timothy Miller
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=200309090119.h891JS307266@owlet.beaverton.ibm.com \
--to=ricklind@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mfedyk@matchmail.com \
--cc=miller@techsource.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®