From: Helge Hafting <helgehaf@aitel.hist.no>
To: Robert Love <rml@tech9.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scheduler hints
Date: Wed, 05 Jun 2002 10:11:02 +0200 [thread overview]
Message-ID: <3CFDC796.C05FC7E2@aitel.hist.no> (raw)
In-Reply-To: <1023206034.912.89.camel@sinai>
Robert Love wrote:
[...]
> Basically, scheduler hints are a way for a program to give a "hint" to
> the scheduler about its present behavior in the hopes of the scheduler
> subsequently making better scheduling decisions. After all, who knows
> better than the application what it is about to do?
>
> For example, consider a group of SCHED_RR threads that share a
> semaphore. Before one of the threads were to acquire the semaphore, it
> could give a "hint" to the scheduler to increase its remaining timeslice
> in order to ensure it could complete its work and drop the semaphore
> before being preempted. Since, if it were preempted, it would just end
> up being rescheduled as the other real-time threads would eventually
> block on the held semaphore.
>
Seems to me this particular case is covered by increasing
priority when grabbing the semaphore and normalizing
priority when releasing.
Only root can do that - but only root does real-time
anyway. And I guess only rood should be able to increase
its timeslice too...
> Other hints could be "I am interactive"
Already shows up as a thread who always ends its timeslice
blocking for io. Such threads do get an priority
boost for the next timeslice.
> or "I am a batch (i.e. cpu hog)
shows up as a thread who spends its entire timeslice - these
don't get the above mentioned boost as it is assumed it gets
"enough cpu" while the interactive threads blocks.
> task" or "I am cache hot: try to keep me on this CPU".
Perhaps that might be useful.
> The scheduler tries hard to figure out the three qualities and it is
> usually right, although perhaps it can react quicker to these hints than
> it can figure things out on its own. If nothing else, this serves as a
> useful tool for determining just how accurate our O(1) scheduler is.
Well, hog/interactive is determined in one timeslice already...
The problem is that this may be abused. Someone nasty could
write a cpu hog that drops a lot of hints about being
interactive, starving real interactive programs.
Generally, it degenerates into application programmers
using _all_ the hints to get performance, so they
can beat some competitor in benchmarks. And all
other programs just get penalized.
Helge Hafting
next prev parent reply other threads:[~2002-06-05 8:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-04 15:53 [PATCH] scheduler hints Robert Love
2002-06-04 17:38 ` Simon Trimmer
2002-06-04 18:07 ` Robert Love
2002-06-05 8:11 ` Helge Hafting [this message]
2002-06-05 10:23 ` Dave Jones
2002-06-05 16:17 ` Robert Love
2002-06-07 11:32 ` Pavel Machek
2002-06-12 18:37 ` Ingo Oeser
2002-06-12 19:39 ` Robert Love
[not found] <no.id>
2002-06-06 0:46 ` Rick Bressler
2002-06-06 0:53 ` Robert Love
2002-06-06 1:14 ` Rick Bressler
2002-06-06 1:05 ` Gerrit Huizenga
2002-06-06 1:11 ` Robert Love
2002-06-06 1:19 ` Gerrit Huizenga
2002-06-10 21:05 ` Bill Davidsen
2002-06-10 22:27 ` Gerrit Huizenga
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=3CFDC796.C05FC7E2@aitel.hist.no \
--to=helgehaf@aitel.hist.no \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@tech9.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.