kern/71833: multiple process disc access / injustice
Arne Woerner
arne_woerner at yahoo.com
Fri Sep 17 15:40:45 PDT 2004
>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 at 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:
More information about the freebsd-bugs
mailing list