public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Timothy Miller <miller@techsource.com>
To: Jeff Sipek <jeffpc@optonline.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Use of AI for process scheduling
Date: Mon, 08 Sep 2003 18:56:26 -0400	[thread overview]
Message-ID: <3F5D091A.6070707@techsource.com> (raw)
In-Reply-To: 200309081755.19777.jeffpc@optonline.net



Jeff Sipek wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I think that this makes sense. It would definitely help with designing the 
> perfect scheduler. One thing tho, I wouldn't use kgdb or any other debugger, 
> instead I would say that /proc or /sys interface would make more sense. 
> Simply copy the weights somewhere else, dissect them, and then act 
> accordingly.
> 
> Jeff.


Well, we have this to deal with:  Someone is exercising the scheduler 
and notices some kind of misscheduling which causes the system to crawl.

How are they going to get to the /proc and /sys directories to do much 
of anything?  The system is completely unresponsive.  Furthermore, even 
if the system IS responsive, we need some way to for the user to hit a 
key and freeze the current state for examination.  Some slow-downs last 
only seconds, but we need to be able to catch them.


You talk about weights.  Would the linux community be willing to put a 
neural net into the kernel?  I'm sure we could optimize it to not take a 
lot of processing overhead, but it's an "unknown".  It would be scary to 
some people to be unable to disect the actual workings of it and have no 
way of determining corner-case behavior from examining code.  But if we 
have, say, only a 2-layer neural net, we might still be able to 
reverse-engineer it.


One thing I was thinking of is that if there is some information about a 
process which is inconvenient to get normally but could be accessed by a 
kernel or user-space thread, then this process could feed back info to 
the scheduler AI for it to do automatic tuning.  Some information that 
the scheduler doesn't have direct (or efficient) access to could be 
inferred from information it DOES have access to, and that would be 
learned through adjustment of weights via backpropogation.


  reply	other threads:[~2003-09-08 22:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-08 19:28 Use of AI for process scheduling Timothy Miller
2003-09-08 21:55 ` Jeff Sipek
2003-09-08 22:56   ` Timothy Miller [this message]
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
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=3F5D091A.6070707@techsource.com \
    --to=miller@techsource.com \
    --cc=jeffpc@optonline.net \
    --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