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