On Tue, 3 Sep 2002, Ingo Molnar wrote:
> On Tue, 3 Sep 2002, Tobias Ringstrom wrote:
>
> > [...] It's a deadline driven semi realtime process.
>
> > [...] 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.
>
> do you see the conflict between your two statements?
Certainly, it's very hard for the kernel to do the right thing. Perhaps
the only viable solution is for the user to solve the problem.
Would it really be so unfair go give the user a way to state that a
process is interactive? The kernel obviously make mistakes. The system
is not fair for users anyway. If a user wants to compete with other
users, he can create more processes to get more CPU.
I'm really concerned about the video decompression/playback situation,
which is quite similar, and can easily take >50% CPU. It also very
inconvenient to have to have superuser support to get good frame rate
stability. A way to define a process as interactive is one way to solve
that problem. Another solution is to let ordinary users use negative nice
values, as you mention below.
> but, i have a spare plan for this, mentioned previously: to enable
> unprivileged processes to lower their priority to -5 if they want to.
> Could you please test your game server, does it feel interactive enough at
> -5?
It helps a little, but the problem is still very visible.
> (allowing -10 might be too much of a stretch.)
Why? If it's using more than 50% CPU, the prio will be the same as a
zero-niced interactive process.
The minimum user nice value might be a good candidate for a new rlimit...
/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:18 EST