From: Jim Houston <jim.houston@attbi.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, andrea@suse.de,
jim.houston@ccur.com
Subject: Re: [PATCH] Re: Pathological case identified from contest
Date: Sun, 20 Oct 2002 22:37:43 -0400 [thread overview]
Message-ID: <3DB36877.9EFF8AA4@attbi.com> (raw)
In-Reply-To: Pine.LNX.4.44L.0210201214010.22993-100000@imladris.surriel.com
Rik van Riel wrote:
>
> On Sat, 19 Oct 2002, Jim Houston wrote:
> > + if (HZ > 100)
> > + return(((p)->prio - MAX_RT_PRIO)*4 + 1);
> > + else
> > + return(((p)->prio - MAX_RT_PRIO)/2 + 1);
> > }
>
> It'd be fun if this code also worked for values of HZ not
> equal to 100 or 1000. Better put HZ somewhere in this
> calculation and make it HZ-independant.
Yes I will clean this up.
> > + * The rq->prio_ind is used to raise/rotate the priority of all of the
> > + * processes in the run queue. I know this sounds like a pyramid scheme.
> > + * This increase in priority is balanced by two feedback mechanisms.
> > + * First processes which consume there timeslice are moved to a lower
> > + * priority queue. To continue the pyramid analogy we make the time
> > + * slice smaller for more favorable priorities.
>
> Sounds like a good strategy, at least in theory. I suspect
> it'll balance itself well enough to also work in practice.
>
> > + * The rotate_rate is the rate at which the priorities of processes
> > + * in the run queue increase. With the initial HZ/10 guess a process
> > + * will go from the worst dynamic priority to the best in 4 seconds.
>
> How long does it take for a best priority process to go
> down ?
I don't know yet. My next step will be to instrument this.
There are a many things that I can be tuned here, but I
want the system to tune itself. For example, I might measure the
interval at which the lowest priority process gets to run and use
this to adjust the rotate_rate.
>
> Or, for how much time can a newly started CPU hog starve
> an older process ? This is important to know since eg.
> a newly started Mozilla could starve an already running
> movie player.
The patch starts new processes with a neutral priority
of 120. If it is a cpu hog, it will get one time slice at
each priority until it reaches the priority where the existing
group of cpu hogs are executing. At this point it will
round robin with this group.
The scheduler has no way to know which processes are interactive. In
your example the user might be waiting for the Mozilla to start
and not care if the movie player skips.
\x18
Jim Houston - Concurrent Computer Corp.
next prev parent reply other threads:[~2002-10-21 2:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-20 3:19 [PATCH] Re: Pathological case identified from contest Jim Houston
2002-10-20 7:33 ` Con Kolivas
2002-10-20 14:31 ` Rik van Riel
2002-10-20 14:28 ` Rik van Riel
2002-10-21 2:37 ` Jim Houston [this message]
2002-10-21 3:27 ` Rik van Riel
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=3DB36877.9EFF8AA4@attbi.com \
--to=jim.houston@attbi.com \
--cc=andrea@suse.de \
--cc=jim.houston@ccur.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=riel@conectiva.com.br \
/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