Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Dec 1997 02:52:18 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        jonny@coppe.ufrj.br (Joao Carlos Mendes Luis)
Cc:        tlambert@primenet.com, chuckr@glue.umd.edu, jonny@coppe.ufrj.br, freebsd-hackers@freebsd.org
Subject:   Re: Process scheduling: nice does not work ???
Message-ID:  <199712120252.TAA07810@usr02.primenet.com>
In-Reply-To: <199712112013.SAA00694@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Dec 11, 97 06:13:19 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> // If he wanted to "lock" priorities, he need to use rtprio.  Otherwise,
> // the scheduler will drift them as it sees fit.
> 
> I don't want to lock priorities.  I want both processes to run, one
> with more time ticks than the other.

The way you do this in Solaris/SVR4 is to used "fixed" as your scheduling
class when you prioctl the thing...

> // IMO, Linux is implementing a "fairness" algorithm based on the NI value;
> 
> Isn't it what NI for ?  If not, what is it for ?

It's for setting your priority to less than the default of 0 so that you
don't bother interactive users with your compute intensive tasks (in
fact, there used to be code in the BSD scheduler to whomp your priority
way down when it determined that your process was non-interactive; I
have no idea when it went away, but it did).


> // I think Linux is wrong, FWIW.
> 
> And Solaris also, by peeking at my measures on the first post.

I didn't gather that from the Solaris numbers.

The thing is that the process percentages are instantaneous.  The
only thing that means anything, really, is the PRI at the next
time the thing is in the ready-to-run-queue with other processes.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712120252.TAA07810>