Date: Fri, 25 Jun 1999 14:23:11 +0200 (MET DST) From: Thomas Schuerger <schuerge@wjpserver.CS.Uni-SB.DE> To: sheldonh@FreeBSD.org Cc: schuerge@cs.uni-sb.de, freebsd-bugs@FreeBSD.org Subject: Re: kern/12381: Bad scheduling in FreeBSD Message-ID: <199906251223.OAA23036@wjpserver.cs.uni-sb.de> In-Reply-To: <199906251128.EAA50171@freefall.freebsd.org> from "sheldonh@FreeBSD.org" at "Jun 25, 1999 04:28:16 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> State-Changed-From-To: open->feedback > State-Changed-By: sheldonh > State-Changed-When: Fri Jun 25 04:27:12 PDT 1999 > State-Changed-Why: > Be careful when defining a compute-bound processes. You need to keep in > mind that if a process sleeps or blocks during its time slice, you must > expect that someone else will get the cpu -- at some point the process > with the high nice value _is_ going to get a time slice. > > You should also keep in mind that FreeBSD (BSD UNIX in general) isn't > optimized for managing two processes. Very few real-world scenarios > require such optimization. It's optimized for the management of many > processes. What I was saying in general is, that FreeBSD's performance drops drastically, if a CPU-intensive process is running in the background. I stated that it mostly affects FreeBSD's I/O performance, which is a problem that other Unix variants don't have (at least not as noticably as with FreeBSD). It would require to take a closer look at how the scheduling is done and maybe a complete rework of that part of the OS. A process in the background should really be "in the background", not interfering with processes in the foreground (nicelevel 0). Very simple tests demonstrate that FreeBSD has a major flaw there. As a simple example, try updating your source tree with cvsup (without the -s flag) and measure the time required. Then start a CPU-intensive process with nicelevel 20 and do the same. You will see that updating the source tree will really take a LOT longer (maybe twice as long), which is not what I'd expect in a Unix environment (in a Windows environment I would, probably. ;-) ). I don't quite understand why you put the other PR from open to closed, because the problems may somewhat be related, but are not the same. Ciao, Thomas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906251223.OAA23036>