Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Apr 2012 13:32:24 -0700 (PDT)
From:      Sushanth Rai <sushanth_rai@yahoo.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Startvation of realtime piority threads
Message-ID:  <1334003544.57349.YahooMailClassic@web180010.mail.gq1.yahoo.com>
In-Reply-To: <201204091437.55505.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
I'm using stock 7.2. The priorities as defined in priority.h are in this ra=
nge:=0A=0A/*=0A * Priorities range from 0 to 255, but differences of less t=
hen 4 (RQ_PPQ)=0A * are insignificant.  Ranges are as follows:=0A *=0A * In=
terrupt threads:           0 - 63=0A * Top half kernel threads:     64 - 12=
7=0A * Realtime user threads:       128 - 159=0A * Time sharing user thread=
s:   160 - 223=0A * Idle user threads:           224 - 255=0A *=0A * XXX If=
/When the specific interrupt thread and top half thread ranges=0A * disappe=
ar, a larger range can be used for user processes.=0A */=0A=0AThe trouble i=
s with vm_waitpfault(), which explicitly sleeps at PUSER.=0A=0A=0ASushanth=
=0A=0A--- On Mon, 4/9/12, John Baldwin <jhb@freebsd.org> wrote:=0A=0A> From=
: John Baldwin <jhb@freebsd.org>=0A> Subject: Re: Startvation of realtime p=
iority threads=0A> To: "Sushanth Rai" <sushanth_rai@yahoo.com>=0A> Cc: free=
bsd-hackers@freebsd.org=0A> Date: Monday, April 9, 2012, 11:37 AM=0A> On Mo=
nday, April 09, 2012 2:08:50 pm=0A> Sushanth Rai wrote:=0A> > I'm on 7.2. s=
ched_sleep() on 7.2 just records the sleep=0A> time. That's why I =0A> thou=
gh _sleep might the right place to do the check.=0A> =0A> Nah, sched_sleep(=
) is more accurate since the sleep priority=0A> can have other =0A> side ef=
fects.=0A> =0A> Hmm, in stock 7.2, the rtprio range is below things like=0A=
> PVM, etc., so that=0A> shouldn't actually be buggy in that regard.=A0 I f=
ixed=0A> this in 9.0 and HEAD=0A> when I moved the rtprio range up above th=
e kernel sleep=0A> priorities.=A0 Are=0A> you using local patches to 7.2 to=
 raise the priority of=0A> rtprio threads?=0A> =0A> > Thanks,=0A> > Sushant=
h=0A> > =0A> > --- On Mon, 4/9/12, John Baldwin <jhb@freebsd.org>=0A> wrote=
:=0A> > =0A> > > From: John Baldwin <jhb@freebsd.org>=0A> > > Subject: Re: =
Startvation of realtime piority=0A> threads=0A> > > To: "Sushanth Rai" <sus=
hanth_rai@yahoo.com>=0A> > > Cc: freebsd-hackers@freebsd.org=0A> > > Date: =
Monday, April 9, 2012, 9:17 AM=0A> > > On Thursday, April 05, 2012 9:08:24=
=0A> > > pm Sushanth Rai wrote:=0A> > > > I understand the downside of badl=
y written=0A> realtime=0A> > > app.=A0 In my case =0A> > > application runs=
 in userspace without making much=0A> syscalls=0A> > > and by all means it =
=0A> > > is a well behaved application. Yes, I can wire=0A> memory,=0A> > >=
 change the application =0A> > > to use mutex instead of spinlock and those=
 changes=0A> should=0A> > > help but they are =0A> > > still working around=
 the problem. I still believe=0A> kernel=0A> > > should not lower the =0A> =
> > realtime priority when blocking on resources. This=0A> can lead=0A> > >=
 to priority =0A> > > inversion, especially since these threads run at=0A> =
fixed=0A> > > priorities and kernel =0A> > > doesn't muck with them.=0A> > =
> >=A0 =0A> > > > As you suggested _sleep() should not adjust=0A> the=0A> >=
 > priorities for realtime =0A> > > threads. =0A> > > =0A> > > Hmm, sched_s=
leep() for both SCHED_4BSD and=0A> SCHED_ULE already=0A> > > does the right=
=0A> > > thing here in HEAD.=0A> > > =0A> > >=A0 =A0=A0=A0if=0A> (PRI_BASE(=
td->td_pri_class) !=3D=0A> > > PRI_TIMESHARE)=0A> > >=A0 =A0 =A0 =A0=A0=A0r=
eturn;=0A> > > =0A> > > Which OS version did you see this on?=0A> > > =0A> =
> > -- =0A> > > John Baldwin=0A> > > =0A> > =0A> =0A> -- =0A> John Baldwin=
=0A> 



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