Date: Fri, 25 Jun 1999 08:20:02 -0700 (PDT) From: "Jose M. Alcaide" <jose@we.lc.ehu.es> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/12381: Bad scheduling in FreeBSD Message-ID: <199906251520.IAA72419@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/12381; it has been noted by GNATS. From: "Jose M. Alcaide" <jose@we.lc.ehu.es> To: Thomas Schuerger <schuerge@wjpserver.CS.Uni-SB.DE> Cc: sheldonh@FreeBSD.ORG, schuerge@cs.uni-sb.de, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/12381: Bad scheduling in FreeBSD Date: Fri, 25 Jun 1999 16:43:22 +0200 Thomas Schuerger wrote: >=20 > > 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 mu= st > > expect that someone else will get the cpu -- at some point the proces= s > > 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. >=20 > 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. >=20 > [snip] Here we are using several FreeBSD systems for running CPU-intensive processes (now including some "setiathome's" ;-) ). All these processes run with nice 20, and their impact in general system performance is very low. In other words, we are not experiencing that performance degradation. Of course, a process which is CPU-bound and also a memory hog has a noticeable impact on performance (due to paging and swapping). However, what I see is that the nice number has little influence on the priority of CPU-bound processes. I think that is due to the way 4.4BSD uses for computing the instant scheduling priority: the recent CPU usage causes a quick degradation of priority. Then, two CPU-intensive processes, one running with nice 5, and another with nice 20, will have the same scheduling priority a few seconds after they start. This does not happen with other UNIXes; for example, two identical processes running with nice 9 and 19 on Solaris, get the 65% and 30% of CPU respectively. Using FreeBSD, both processes get the 50% of the CPU. -- JMA ----------------------------------------------------------------------- Jos=E9 M=AA Alcaide | mailto:jose@we.lc.ehu.es Universidad del Pa=EDs Vasco | mailto:jmas@es.FreeBSD.ORG Dpto. de Electricidad y Electr=F3nica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-946013071 ----------------------------------------------------------------------- "Go ahead... make my day." - H. Callahan 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?199906251520.IAA72419>