Date: Fri, 28 Nov 2008 21:48:32 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: David Xu <davidxu@freebsd.org> Cc: freebsd-bugs@freebsd.org, Unga <unga888@yahoo.com>, jhb@freebsd.org, jeff@freebsd.org, Jeff Roberson <jroberson@jroberson.net>, brde@optusnet.com.au, yanefbsd@gmail.com Subject: Re: kern/129164: Wrong priority value for normal processes Message-ID: <20081128210532.Y1244@besplex.bde.org> In-Reply-To: <492F5BE0.2040200@freebsd.org> References: <484904.78100.qm@web57001.mail.re3.yahoo.com> <20081127000235.D971@desktop> <492F5BE0.2040200@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 Nov 2008, David Xu wrote:
> This might be caused by following code in sched_ule.c:
No, this is mostly user confusion -- see a previous reply.
> static void
> sched_priority(struct thread *td)
> {
> int score;
> int pri;
>
> if (td->td_pri_class != PRI_TIMESHARE)
> return;
> /*
> * If the score is interactive we place the thread in the realtime
> * queue with a priority that is less than kernel and interrupt
> * priorities. These threads are not subject to nice restrictions.
> *
> * Scores greater than this are placed on the normal timeshare queue
> * where the priority is partially decided by the most recent cpu
> * utilization and the rest is decided by nice value.
> *
> * The nice value of the process has a linear effect on the
> calculated
> * score. Negative nice values make it easier for a thread to be
> * considered interactive.
> */
> score = imax(0, sched_interact_score(td) - td->td_proc->p_nice);
> if (score < sched_interact) {
> pri = PRI_MIN_REALTIME;
> pri += ((PRI_MAX_REALTIME - PRI_MIN_REALTIME) /
> sched_interact)
> * score;
> KASSERT(pri >= PRI_MIN_REALTIME && pri <= PRI_MAX_REALTIME,
> ("sched_priority: invalid interactive priority %d score
> %d",
> pri, score));
> } else {
>
>
> it uses PRI_MIN_REALTIME, then it calls sched_user_prio(td, pri) which sets
> td_base_user_pri and td_user_pri, and causes td_user_pri and td_base_user_pri
> to be out of range.
They are out of normal range for a PRI_TIMESHARE user thread, but this is
intentional -- the thread is supposed to temporarily act like a
PRI_REALTIME one -- see the comment.
> Should PRI_MIN_REALTIME and PRI_MAX_REALTIME be
> PRI_MIN_TIMESHARE and PRI_MAX_TIMESHARE ?
No, they should be the PRI_REALTIME limits like they are.
The user confusion is that the garbage returned by rtprio(RTP_LOOKUP,
...) for PRI_TIMESHARE processes is interpreted as a realtime priority.
The garbage was originally 0, but is now supposed to be (for no good
reason) the current base user priority. In either case, it has very
little to do with the realtime priority, so I call it garbage. Its
upper limit has always been out of bounds for a realtime priority, and
the above code makes it go negative and thus its lower limit is out
of bounds for a realtime priority too. Since realtime priorities are
unsigned, going below the lower limit just gives more obvious garbage
by misrepresenting a negative value in a u_short.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081128210532.Y1244>