Subject: Re: sched_changepri, and priority levels
To: Matt Thomas <matt@3am-software.com>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: tech-kern
Date: 03/06/2007 20:18:30
On Tue, 6 Mar 2007 17:08:37 -0800
Matt Thomas <matt@3am-software.com> wrote:

> 
> On Mar 6, 2007, at 5:03 PM, Jason Thorpe wrote:
> 
> >
> > On Mar 6, 2007, at 10:17 AM, Matt Thomas wrote:
> >
> >> I'd like a portion of kernel above real time as well at below.
> >>
> >> 192 - 255       Interrupt (64)
> >> 160 - 191    Kernel high (32)
> >> 96 - 159        Real time (64)
> >> 64 - 95         Kernel low (32)
> >> 0 - 63          User (64)
> >
> > If the goal is to have kernel real-time threads, then let's call it
> > > like it is:
> >
> > 192 - 255     Interrupt (64)
> > 160 - 191     Kernel real-time (32)
> >  96 - 159     User real-time (64)
> >  64 -  95     Kernel
> >   0 -  63     User (64)
> >
> > That said, I'm a bit uneasy with "user process with real-time >
> > threads can starve kernel threads".
> 
> which is why I wanted kernel realtime.  Note that the recently
> committed OSK5912 support in evbarm supports 160 interrupt sources,
> so having lots of interrupt priorities gives a lot of flexibility on
> those interrupts.
> 
What are the restrictions on user real-time?  Put another way, what
privileges does a user-level application need to have to be able to
starve kernel threads?  Root?  Something lesser?  If so, what?

Mind you, I don't disagree; I like listening to drop-out free music,
too.  But I also don't want X and xterm to be locked out by a buggy
and/or malicious application.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb