From: Jim Houston <jim.houston@ccur.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Jim Houston <jim.houston@attbi.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: O(1) Scheduler (tuning problem/live-lock)
Date: Thu, 03 Oct 2002 01:50:34 -0400 [thread overview]
Message-ID: <3D9BDAAA.B31E0D48@ccur.com> (raw)
In-Reply-To: 20021002064559.GB1158@dualathlon.random
Hi Andrea, Ingo,
Andrea, I tried your second patch. Again, it keeps on running even with
"waitpid06 -c 16 -i 10000". This is good. It still has some jerky
mouse behavior (under this load). This is on an old slow Pentium Pro
dual processor. If I grab a window and move it around for several
seconds, the screen will freeze for a couple seconds. I suspect that
my X server fails the TASK_INTERACTIVE test.
I have been hacking at sched.c myself trying to avoid the array switch
entirely. I'm trying to set up a self-tuning feedback mechanism to
adjust priorities so everything gets some cpu time without
having to do the array switch. I'm juggling these ideas:
1. Gradually raise the priority of all the processes in
the run queue. Do this without having to visit all
of the processes.
2. When a process uses up its time slice, move it to a
less favorable priority.
3. Tune the sleep_avg. I like the old decaying average
approach of old unix systems. The current sleep_avg
goes to saturation too often. I would like to
be able to tell if a process has been using more than
its share of the cpu time.
4. Make the maximum time slice decrease with more favorable
priorities. The time slice would depend on the dynamic
priority.
I have code hacked together for first idea but its not useful without
the rest.
Jim Houston - Concurrent Computer Corp.
prev parent reply other threads:[~2002-10-03 5:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-06 18:44 O(1) Scheduler (tuning problem/live-lock) Jim Houston
2002-09-30 16:10 ` Andrea Arcangeli
2002-10-01 7:20 ` Jim Houston
2002-10-02 6:45 ` Andrea Arcangeli
2002-10-03 5:50 ` Jim Houston [this message]
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=3D9BDAAA.B31E0D48@ccur.com \
--to=jim.houston@ccur.com \
--cc=andrea@suse.de \
--cc=jim.houston@attbi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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;
as well as URLs for NNTP newsgroup(s).