Re: O(1) scheduler & interactivity improvements

[Jesse Pollard]

On Sunday 22 June 2003 15:00, Davide Libenzi wrote:
> 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.

Wait a minute... A word processor that waits 24 hours to recieve an input is
IDLE for everything except file save/checkpoint.

No CPU utilization at all.

What SHOULD happen gradually is that it's memory (RSS) should be trimmed due
to lack of activity.

The processor priority should/could stay the same (or even go higher). That
way the applications gets a chance to page in necessary data AS SOON as the
input IS available.

The described word processor is a MEMORY scheduling issue, not an interactive
scheduling issue.

Interactive jobs can be identified by having short term sleep events occuring
before (more often than) timeslice consumption. These processes could use a
priority boost (special conditions do occurr with polling without a timeout).

Those processes that exhaust a timeslice frequently are CPU bound, with 
little I/O involved. These could do with a reduced priority (again, some
special conditions do occur with poll).