On 5/25/06, Wolfgang Woehl <tito@xxxxxxxxxx> wrote:
Wednesday 24 May 2006 02:01, Lee Revell: > On Thu, 2006-05-25 at 01:55 +0200, Wolfgang Woehl wrote: > > Damn, it doesn't make sense to me. If I can configure the kernel to be > > or not to be preemptible then what is the separation good for? Isn't > > overhead because of preemption the only price tag? > > You are confusing preemption (which improves the performance of realtime > processes) with the permission to run realtime processes at all > (addressed by the realtime LSM, pam, or set_rtlimits). Err, no. I doubt the need for this restriction. A campus server kernel wouldn't be configured for preemption, a dedicated workstation would be. Why put another roadblock in the way?
One is a mechanism, useful in many domains. The other controls who has access to that mechanism. Some systems don't care (yours pehaps?), others care very much. There is nothing wrong with this as a system design concept. What you and many of us are suffering from is the balkanized implementation of Linux kernels and distributions. The kernel group made some implementation choices a year ago. While those choices were OK, they did not worry about all the peripheral pieces needed to gather them into a useable end-user package. That is not their job. The required components are now available, and are being provided by a few leading-edge distributions. Had you installed Ubuntu Dapper Drake (which is not yet officially released), you would not have seen any problem. They chose to include the PAM patches and authorize all users to start realtime threads be default. That is a reasonable choice for them (given their goals), but would not be appropriate for most other distributions. -- joq
