public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox