From owner-freebsd-bugs@FreeBSD.ORG Fri Sep 17 22:40:44 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 917F616A4EF for ; Fri, 17 Sep 2004 22:40:44 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2941F43DCB for ; Fri, 17 Sep 2004 22:40:32 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i8HMeWKv057964 for ; Fri, 17 Sep 2004 22:40:32 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i8HMeWbl057956; Fri, 17 Sep 2004 22:40:32 GMT (envelope-from gnats) Resent-Date: Fri, 17 Sep 2004 22:40:32 GMT Resent-Message-Id: <200409172240.i8HMeWbl057956@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Arne Woerner Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E071E16A4CF for ; Fri, 17 Sep 2004 22:33:28 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id D532D43D3F for ; Fri, 17 Sep 2004 22:33:28 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i8HMWHEE087103 for ; Fri, 17 Sep 2004 22:32:17 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.12.11/8.12.11/Submit) id i8HMWHmN087102; Fri, 17 Sep 2004 22:32:17 GMT (envelope-from nobody) Message-Id: <200409172232.i8HMWHmN087102@www.freebsd.org> Date: Fri, 17 Sep 2004 22:32:17 GMT From: Arne Woerner To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: kern/71833: multiple process disc access / injustice X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 22:40:45 -0000 >Number: 71833 >Category: kern >Synopsis: multiple process disc access / injustice >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Fri Sep 17 22:40:31 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Arne Woerner >Release: 5.2-CURRENT-20040408-JPSNAP >Organization: >Environment: FreeBSD neo.riddick.homeunix.org 5.2-CURRENT-20040408-JPSNAP FreeBSD 5.2-CURRENT-20040408-JPSNAP #76: Wed Apr 21 13:45:34 GMT 2004 aw@neo.riddick.homeunix.org:/usr/src/sys/i386/compile/DAREDEVIL i386 >Description: I saw several times, that two processes who compete about disc access (same disc) and who need different transfer-rates (e. g. mplayer (read 100KBytes/sec; nice 0) and fsck -p -B (read/write ???MBytes/sec; nice +4)) behave not so optimal: The one have wants more data in the same time wins, even though it has a higher nice value, and even though the other process has quite moderate needs (I think my mplayer process just needs below 1% of the possible bandwidth). Although I am surely not the first one, and although my FreeBSD version is not the newest, I would like to recommend kindly to use a similar scheduler like for the processor (maybe it would be even possible to find a sequence of disc access, that would be faster while still meeting the requirements of the processes (I was thinking of moving the disc heads around: if there is (1.) a read request near the centre and (2.) a write request near the border and (3.) a write request near the centre, then the sequence 1.->3.->2. looks better to me)). Since I have 512MB main memory space, I do not think, that this is caused by a lack of main memory... Sorry if my idea is too spaced off... :-) -Arne >How-To-Repeat: 1. start a high access rate process (like fsck -p -B) 2. start a low access rate process (like mplayer on a 1000kbit/sec movie) 3. I can see that mplayer hangs a little bit (btw.: even a xterm and a tcsh shell process would behave slower) >Fix: Just theoretically... But I would like to assist such development... >Release-Note: >Audit-Trail: >Unformatted: