On Tue, 3 Sep 2002, Ingo Molnar wrote:
> do you expect a task that uses up 50% CPU time over an extended period of
> time to be rated 'interactive'?
Interactive is not the best word, but I would not expect a process like
the one I described to be considedred a CPU hog. It's a deadline driven
semi realtime process.
> we might make the '50%' rule to be '100% / nr_running_avg', so that if
> your task is the only one in the system then it gets rated interactive -
> but i suspect it will still be rated a CPU hog if it keeps trying to use
> up 50% of CPU time even during busier periods. I have tried the
> (1/nr_running) rule in earlier incarnations of the scheduler, and it didnt
> make much difference, but we obviously need a boundary case like yours to
> see the differences.
I think the problem I have (that I loose a lot of performance to processes
such as crond, httpd, etc.) is common to the whole class of semi-realtime
processes, at least if they use >50% CPU. This means that CPU intensive
audio and video (e.g. DVD) playback programs might have the same problem.
I see three simple ways to solve the problem without changing the
scheduler. Either run the process with nice -20, use SCHED_RR, or use a
dedicated server with no other processes (such as crond, httpd, etc).
The first two might be OK, but you need root privilegies to run renice and
to change the scheduler policy. The third one is not an option for all
users, and definately not for the video playback case.
A problem is that this new scheduler behaviour will hit people running
semi realtime processes as a regression when they switch to 2.6. It would
be nice to avoid that.
One solution might be to teach the scheduler how to detect these deadline
driven semi-realtime processes, and not punish them. It is not obvious to
me how to do that.
Another much simpler solution that might work just as well is be to change
the CPU utilization threshold from 50% to 90%.
You're the expert of course. I'm only fumbling in the dark... :-)
> (it could in theory make a difference in some rare cases, in which the
> frequency of sampling resonates with internal timings of the application -
> i asked for this only to make sure there are no interactions.)
I'll try it out and let you know if it does make a difference.
/Tobias
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:17 EST