Date: Tue, 5 Mar 2002 09:47:18 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: kernel process priority question... Message-ID: <Pine.BSF.4.21.0203050939430.26829-100000@InterJet.elischer.org> In-Reply-To: <20020305223033.M4715-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
The person to ask is jhb, but I think that the first option is closest.
td_base_pri is the base kernel priority that the process has WITHOUT
PRIORITY INHERRITANCE. This is what is increased (or should be)
when you specify a priority in msleep, and it wakes up.
The instant priority is td->td_priority.
This is what the priority is right now, including priority
inheritance from mutexes wanted by others. When you go back to userland
yuor priority will be reset back to kg->kg_user_pri, which is common for
all thread in the scheduling group.
If you are changing td_base_pri, you may need to change td_priority as
well if you want it to have any effect. (I need to look at msleep to
see if this is done right)
td->td_priority = min(td->td_base_pri, td->td_priority);
i.e. if the new base pri is more (lower than) the current priority,
then boost the current priority too.
On Tue, 5 Mar 2002, Bruce Evans wrote:
> On Mon, 4 Mar 2002, Poul-Henning Kamp wrote:
>
> > What is the correct way to set a priority on a kernel thread ?
> >
> > Is it legal to simply set the value like this:
> >
> > curthread->td_base_pri = PRIBIO;
> >
> > Or should the detour around the rtprio stuff be used:
> >
> > struct rtprio rtp;
> >
> > rtp.prio = RTP_PRIO_MAX;
> > rtp.type = RTP_PRIO_IDLE;
> > mtx_lock_spin(&sched_lock);
> > rtp_to_pri(&rtp, td->td_ksegrp);
> > mtx_unlock_spin(&sched_lock);
>
> Neither.
>
> The rtprio stuff should be just compatibility cruft to support the
> rtprio(2) mistake (extending {get,set}priority(2) would have been a
> smaller mistake, but even these were obsoleted by the POSIX.1-1993
> about a year before rtprio(2) was committed).
>
> When setting priority fields directly, there are 4 of them in places
> that keep being moved by KSE changes, and the setting may need locking,
> so a function to hide the details would be useful. rtp_to_prio() is
> not that function.
>
> Bruce
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203050939430.26829-100000>