Date: Sat, 28 Feb 2004 06:28:24 +0100 From: Erik Trulsson <ertr1013@student.uu.se> To: Zhang Weiwu <zhangweiwu@realss.com> Cc: questions@freebsd.org Subject: Re: scheduling priority not working? Message-ID: <20040228052824.GA76835@falcon.midgard.homeip.net> In-Reply-To: <404021DB.6070009@realss.com> References: <Law11-F55YR6CsSTJUj00012ecb@hotmail.com> <20040228035629.GA66561@falcon.midgard.homeip.net> <404021DB.6070009@realss.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 28, 2004 at 01:06:35PM +0800, Zhang Weiwu wrote:
> Erik Trulsson wrote:
>
> >On Sat, Feb 28, 2004 at 11:37:51AM +0800, Zhang Weiwu wrote:
> >
> >
> >>Hello. I thought scheduling priority is the kind of absolute priority,
> >>that is only when the higher priority process don't ask for resource, can
> >>the lower priority process gets resource. If the higher priority process
> >>sucks, the lower priority process starvs.
> >>
> >>Now I have a old Pentium-mmx 166 box, running mpg321 fine. I wish to
> >>listen to music when recompile the kernel, so turn on the music, do:
> >>#nice make;
> >>I thought "nice make" use the resouce mpg321 left to it, but actually the
> >>music process is seriously disturbed, it begins to sound like ....
> >>terrible.
> >>
> >>So I don't realy understand the scheduling priority mechnism in FreeBSD?
> >>
> >>
> >
> >No, you dont quite understand the scheduling.
> >There are actually two different priorities that influence scheduling.
> >If you look at the output from top(1) you can see them in the columns
> >labeled 'PRI' and 'NICE'. The first one ('PRI') is the one that is
> >actually used to determine when a process gets to run. This is
> >dynamically adjusted by the system to make sure that all processes get
> >at least *some* CPU-time (so no process can be completely starved.) The
> >second ('NICE') is what is changed by the nice/renice commands and
> >affects how the actual priority is changed by the system. (Processes
> >with a high nice-value essentially gets their priority raised slowly
> >and lowered quickly .)
> >
> >
> I don't understand. I watched top(1) for some time, it seems the mpg321
> process, having NICE=-20, keep constant PRI of 108~110, but other
> processes like 'yacc', 'cc', although running at NICE=4, comes out even
> at PRI=120, and almost keep that high until it finish its work in
> several seconds and quit, meanwhile the speaker keep producing broken
> music. If NICE=-20 processes cannot have more PRI than NICE=4, what's
> the use of NICE?
Try comparing two CPU-hungry processes that both run for a long time
and you will see the difference.
Processes which do a lot of I/O and don't use much CPU tends to get
fairly high priority. Processes also tend to start with relatively high
priority so a short-lived process will not have had time to get its
priority adjusted much regardless of its nice-level.
>
> >I run at a very similar box, but use mpg123 rather than mpg321, and I
> >can play music without significant disturbance.
> >You might wish to try mpg123 instead, in my experience it needs less
> >CPU-power than mpg321.
> >
> >
> My mpg123 hangs after copyright notice. It's another story though.
>
> >You could also try using a higher nice value for the make process. (i.e
> >run it with 'nice -19 make' or something like that.)
> >
> >
> I tried 'nice -n 19 make' which gives 'badly formed number' error. 'nice
> -19 make' made 'make' even greedy.
Let me guess: You are using [t]csh as your shell, right?
That has 'nice' as a built-in command with a slightly different syntax
than /usr/bin/nice (which is what is documented in the nice(1)
manpage)
--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040228052824.GA76835>