Date: Sat, 13 Mar 1999 13:51:57 +1000 From: Greg Black <gjb@comkey.com.au> To: Thomas Schuerger <schuerge@wurzelausix.CS.Uni-SB.DE> Cc: freebsd-questions@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Scheduling bug? Message-ID: <19990313035157.4099.qmail@alpha.comkey.com.au> In-Reply-To: <199903111631.RAA03067@wurzelausix.cs.uni-sb.de> of Thu, 11 Mar 1999 17:31:11 %2B0100 References: <199903111631.RAA03067@wurzelausix.cs.uni-sb.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > When having two processes running, one with nice-level 0,
> > > > the other one with nice-level 19 and both consuming as much
> > > > CPU time as possible (e.g. an endless loop), FreeBSD will do
> > > > a 2:1 time-slicing (that is, the first process will get 66%
> > > > of the CPU-time and the other one 33%). For a test, just
> > > > start two Perl processes doing a "while(1) {}", renice one
> > > > of the processes to 19 and watch the "top" output.
> >
> > [...]
> >
> > > It's impossible given the test that you created to accurately
> > > _measure_ this difference, as you're relying on an interpreted
> > > (perl) loop - I'd be interested to see the same results with an
> > > executable that was looping - so as to remove the layer of the
> > > interpreter.
> >
> > The real point is that top is a useless tool when it comes to
> > this kind of comparisons. You're just as likely seeing
> > variations in the performance of top, as learning anything about
> > the actual time slices.
> >
> > FreeBSD may suck in this area, but you'd have to do some proper
> > testing to find out. This means writing some code that does
> > useful work (never busy loops) and measuring the amount of work
> > that gets done. It's harder than it sounds.
>
> I'd say that this is proper testing. I am running the RC5 keycrack
> client in the background (www.distributed.net), which can be
> considered as being an endless loop with no disk/network i/o
> (disk/network is accessed once within some hours).
> The process is automatically running with nice-level 19.
>
> Now, anything that's cpu-intensive in the foreground (e.g. compilation,
> GIMP or whatever) will get only 66% of the cpu-time, because the
> background process is not scheduled properly (this is not a matter
> of what 'top' displays, it's what can really be measured when e.g.
> applying effects in GIMP to an image). Even when doing disk
> i/o in the foreground, like when rebuilding the 'locate' database,
> this will be a lot slower. When killing the background process while
> rebuilding the 'locate' database, the harddisk accesses are much more
> frequent and it terminates a lot earlier.
This story is very different from the information that was first
posted and points to the reason why people constantly advise you
to post all the relevant information in the first place so that
other people won't waste their time answering questions that
turn out not to be the real question.
I don't have time to look at real examples right now, but I'd
agree that the behaviour you describe here is far from optimal,
assuming the picture you paint is accurate.
--
Greg Black <gjb@acm.org>
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?19990313035157.4099.qmail>