Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 3 Sep 2002 13:50:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 3 Sep 2002 13:50:44 -0400 Received: from h181n1fls11o1004.telia.com ([195.67.254.181]:33929 "EHLO ringstrom.mine.nu") by vger.kernel.org with ESMTP id ; Tue, 3 Sep 2002 13:50:43 -0400 Date: Tue, 3 Sep 2002 19:55:09 +0200 (CEST) From: Tobias Ringstrom X-X-Sender: tori@boris.prodako.se To: Ingo Molnar cc: Alan Cox , Kernel Mailing List Subject: Re: Problem with the O(1) scheduler in 2.4.19 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2206 Lines: 51 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/