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