Re: [PATCH] scheduler hints

[Helge Hafting]

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