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 <j...@freebsd.org> wrote: > From: John Baldwin <j...@freebsd.org> > Subject: Re: Startvation of realtime piority threads > To: "Sushanth Rai" <sushanth_...@yahoo.com> > Cc: freebsd-hackers@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 <j...@freebsd.org> > wrote: > > > > > From: John Baldwin <j...@freebsd.org> > > > Subject: Re: Startvation of realtime piority > threads > > > To: "Sushanth Rai" <sushanth_...@yahoo.com> > > > Cc: freebsd-hackers@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 > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
