From: Davide Libenzi <davidel@xmailserver.org>
To: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: O(1) scheduler & interactivity improvements
Date: Sun, 22 Jun 2003 13:00:11 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.55.0306221238230.15064@bigblue.dev.mcafeelabs.com> (raw)
In-Reply-To: <1056298069.601.18.camel@teapot.felipe-alfaro.com>
On Sun, 22 Jun 2003, Felipe Alfaro Solana wrote:
> Hi all,
>
> I must say I'm a little bit disappointed with the interactive feeling of
> latest kernels. From what I have read, it seems the scheduler decides on
> the "interactive" behavior of a process based on its CPU usage and
> sleeping times. I am no kernel expert, so I will assume this is how it
> works, more or less, behind the scenes.
>
> I think that marking a process as "interactive" based on the previous
> premise is quite unreal. Let's take, for example, a real application
> like a word processor which performs background spell checking. The word
> processor should be considered interactive, even when it may be hogging
> the CPU a lot to perform the background spell check and the rest of its
> threads are sleeping waiting for user input.
I'm sorry to disagree. A word processor that waited 24 hours to receive an
input should be *gradually* migrated to lower priorities (CPU hogs) when
it starts eating all its timeslice. You can tune how *gradually* (negative
feedback) you move the process, but you can't bolt in explicit rules into
the scheduler. If your word processor that was waiting by 24 hours will
start eating all its timeslice, it must be migrated down in priority. When
the spell check will be over, it'll re-gain its status of interactive task.
One suggestion for Ingo would be to use the previous task history to
compute how gradually to migrate the task, with a factor for each direction.
Processes with a long history of interactive tasks should have a brake
when migrating towards lower priorities, like the ones that showed CPU
hogs properties repeatedly should have a brake when moving to higher
priorities. The value of this "brake" should be made function of the
previous history.
- Davide
next prev parent reply other threads:[~2003-06-22 19:47 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-22 16:07 Felipe Alfaro Solana
2003-06-22 20:00 ` Davide Libenzi [this message]
2003-06-23 12:50 ` Jesse Pollard
2003-06-23 8:09 ` Helge Hafting
2003-06-23 10:18 ` Felipe Alfaro Solana
2003-06-23 16:21 ` Daniel Gryniewicz
2003-06-23 18:59 ` Felipe Alfaro Solana
2003-06-23 19:21 ` Memory? " Roger Larsson
2003-06-23 16:47 ` Helge Hafting
2003-06-24 18:12 ` Bill Davidsen
2003-06-25 21:41 ` Helge Hafting
[not found] ` <5.2.0.9.2.20030624215008.00ce73b8@pop.gmx.net>
2003-06-26 9:59 ` Helge Hafting
2003-06-26 10:39 ` Mike Galbraith
2003-06-26 14:50 ` Bill Davidsen
2003-06-26 23:10 ` Timothy Miller
[not found] ` <Pine.LNX.3.96.1030626104733.17562D-100000@gatekeeper.tmr.c om>
2003-06-27 6:36 ` Mike Galbraith
2003-06-27 8:18 ` Helge Hafting
2003-06-27 9:46 ` Mike Galbraith
2003-06-27 11:39 ` Helge Hafting
2003-06-27 12:18 ` Mike Galbraith
2003-06-28 3:51 ` Bill Davidsen
[not found] ` <Pine.LNX.3.96.1030627234408.25848A-100000@gatekeeper.tmr.c om>
2003-06-28 5:44 ` Mike Galbraith
2003-06-28 14:34 ` Helge Hafting
2003-06-29 6:08 ` Mike Galbraith
2003-06-30 13:37 ` Bill Davidsen
2003-06-27 6:54 ` jw schultz
2003-06-23 10:50 John Bradford
2003-06-23 11:22 ` Felipe Alfaro Solana
2003-06-23 11:36 ` Denis Vlasenko
2003-06-23 12:44 John Bradford
2003-06-23 16:32 ` Helge Hafting
2003-06-23 19:00 ` Felipe Alfaro Solana
2003-06-23 19:17 ` Helge Hafting
2003-06-24 22:41 ` Timothy Miller
2003-06-25 21:42 ` Helge Hafting
2003-06-25 23:16 ` Timothy Miller
2003-06-23 21:48 ` Bill Davidsen
2003-06-23 19:20 John Bradford
2003-06-23 23:32 John Bradford
2003-06-24 4:13 ` Bill Davidsen
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=Pine.LNX.4.55.0306221238230.15064@bigblue.dev.mcafeelabs.com \
--to=davidel@xmailserver.org \
--cc=felipe_alfaro@linuxmail.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®