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
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?
> --- On Mon, 4/9/12, John Baldwin <jhb@free...> wrote:
> > From: John Baldwin <jhb@free...>
> > Subject: Re: Startvation of realtime piority threads
> > To: "Sushanth Rai" <sushanth_rai@yaho...>
> > Cc: freebsd-hackers@free... > > 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