Startvation of realtime piority threads

[Sushanth Rai]

I'm using stock 7.2. The priorities as defined in priority.h are in this range:

/*
 * Priorities range from 0 to 255, but differences of less then 4 (RQ_PPQ)
 * are insignificant.  Ranges are as follows:
 *
 * Interrupt threads:           0 - 63
 * Top half kernel threads:     64 - 127
 * Realtime user threads:       128 - 159
 * Time sharing user threads:   160 - 223
 * Idle user threads:           224 - 255
 *
 * XXX If/When the specific interrupt thread and top half thread ranges
 * disappear, a larger range can be used for user processes.
 */

The trouble is with vm_waitpfault(), which explicitly sleeps at PUSER.


Sushanth

--- On Mon, 4/9/12, John Baldwin <jhb at freebsd.org> wrote:

> From: John Baldwin <jhb at freebsd.org>
> Subject: Re: Startvation of realtime piority threads
> To: "Sushanth Rai" <sushanth_rai at yahoo.com>
> Cc: freebsd-hackers at freebsd.org
> Date: Monday, April 9, 2012, 11:37 AM
> On Monday, April 09, 2012 2:08:50 pm
> Sushanth Rai wrote:
> > I'm on 7.2. sched_sleep() on 7.2 just records the sleep
> time. That's why I 
> though _sleep might the right place to do the check.
> 
> Nah, sched_sleep() is more accurate since the sleep priority
> can have other 
> side effects.
> 
> Hmm, in stock 7.2, the rtprio range is below things like
> PVM, etc., so that
> shouldn't actually be buggy in that regard.  I fixed
> this in 9.0 and HEAD
> when I moved the rtprio range up above the kernel sleep
> priorities.  Are
> you using local patches to 7.2 to raise the priority of
> rtprio threads?
> 
> > Thanks,
> > Sushanth
> > 
> > --- On Mon, 4/9/12, John Baldwin <jhb at freebsd.org>
> wrote:
> > 
> > > From: John Baldwin <jhb at freebsd.org>
> > > Subject: Re: Startvation of realtime piority
> threads
> > > To: "Sushanth Rai" <sushanth_rai at yahoo.com>
> > > Cc: freebsd-hackers at freebsd.org
> > > Date: Monday, April 9, 2012, 9:17 AM
> > > On Thursday, April 05, 2012 9:08:24
> > > pm Sushanth Rai wrote:
> > > > I understand the downside of badly written
> realtime
> > > app.  In my case 
> > > application runs in userspace without making much
> syscalls
> > > and by all means it 
> > > is a well behaved application. Yes, I can wire
> memory,
> > > change the application 
> > > to use mutex instead of spinlock and those changes
> should
> > > help but they are 
> > > still working around the problem. I still believe
> kernel
> > > should not lower the 
> > > realtime priority when blocking on resources. This
> can lead
> > > to priority 
> > > inversion, especially since these threads run at
> fixed
> > > priorities and kernel 
> > > doesn't muck with them.
> > > >  
> > > > As you suggested _sleep() should not adjust
> the
> > > priorities for realtime 
> > > threads. 
> > > 
> > > Hmm, sched_sleep() for both SCHED_4BSD and
> SCHED_ULE already
> > > does the right
> > > thing here in HEAD.
> > > 
> > >     if
> (PRI_BASE(td->td_pri_class) !=
> > > PRI_TIMESHARE)
> > >         return;
> > > 
> > > Which OS version did you see this on?
> > > 
> > > -- 
> > > John Baldwin
> > > 
> > 
> 
> -- 
> John Baldwin
>