From owner-freebsd-threads@FreeBSD.ORG Sun Apr 20 04:20:01 2008 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76589106566C for ; Sun, 20 Apr 2008 04:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 54E408FC19 for ; Sun, 20 Apr 2008 04:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3K4K1A2027254 for ; Sun, 20 Apr 2008 04:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3K4K1Y7027253; Sun, 20 Apr 2008 04:20:01 GMT (envelope-from gnats) Resent-Date: Sun, 20 Apr 2008 04:20:01 GMT Resent-Message-Id: <200804200420.m3K4K1Y7027253@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, bob frazier Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D214B106566B for ; Sun, 20 Apr 2008 04:12:49 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id C21FC8FC17 for ; Sun, 20 Apr 2008 04:12:49 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m3K4CWlk005360 for ; Sun, 20 Apr 2008 04:12:32 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m3K4CWMI005359; Sun, 20 Apr 2008 04:12:32 GMT (envelope-from nobody) Message-Id: <200804200412.m3K4CWMI005359@www.freebsd.org> Date: Sun, 20 Apr 2008 04:12:32 GMT From: bob frazier To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/122923: 'nice' does not prevent background process from stealing CPU from foreground X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2008 04:20:01 -0000 >Number: 122923 >Category: threads >Synopsis: 'nice' does not prevent background process from stealing CPU from foreground >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Apr 20 04:20:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: bob frazier >Release: 7-STABLE >Organization: SFT Inc. >Environment: FreeBSD hack.SFT.local 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Apr 1 01:11:09 PDT 2008 root@hack.SFT.local:/usr/obj/usr/src/sys/GENERIC i386 >Description: When a background process that is CPU intensive is 'renice'd to 19, it will still affect foreground processes (such as watching a movie with vlc) such that 'stuttering' or obvious lapses in process scheduling can easily be observed. Removing the background process entirely alleviates the 'intermittent response' or 'stuttering' problem. In its worst state the 'stuttering' seems to allow about 1/2 second 'bursts' of CPU for the foreground, then the background process, then the foreground again, when CPU utilization in the foreground approaches the 100% mark (like decoding an H.264 movie). Using 'idprio' to TRULY move the background process into the background can make it possible to leave the background process running and NOT cause significant performance problems in the foreground. However, the behavior I describe here did NOT exist in 6.3 and should not require this kind of workaround. In my search for similar bug reports, I found a behavior described in 'ports/118645' where mouse response was 'intermittent' or 'stuttering' while a background process used a lot of CPU. I have also observed this particular mouse behavior on rare occasions, once precedeeding a system crash (see kern/122615). >How-To-Repeat: a) run a CPU-intensive process with 'nice 19' (such as 'dnetc' from ports), one that does not already move itself into an 'idle priority' class. b) run the 'XAnalogTV' x screensaver under X11. Observe intermittent display updates. [Alternately play a video with vlc that requires >50% cpu to decode, ideally with divx or h.264 encoding] c) use 'idprio' to move the dnetc process into one of the lowest possible priority classes (idle 30) d) run the 'XAnalogTV' screensaver (or video) again >Fix: A workaround can be achieved by using 'idprio' to move the background process into the idle priority class as described above. This appears to have the same effect on the process that 'renice 19' had in 6.3 . >Release-Note: >Audit-Trail: >Unformatted: