Startvation of realtime piority threads
Sushanth Rai
sushanth_rai at yahoo.com
Mon Apr 9 18:09:58 UTC 2012
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.
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
>
More information about the freebsd-hackers
mailing list