On Fri, 2005-04-08 at 05:12 -0400, Jean-Marc Valin wrote: Ingo's patch allows 3 to be done in userspace, by an "RT watchdog" process that runs as root, and wakes occasionally to check for runaway RT tasks & kill or demote them. I think they are already convinced. It looks like Ingo's solution will get merged (it's in -mm already).

Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu> writes: Difficult and frustrating. The kernel developers have decided not to merge the realtime-lsm, after all.

Instead, they propose an rlimits extension for granting per-user realtime scheduling privileges. This does (barely) meet our minimum needs.

It is inferior to the realtime-lsm solution for several reasons I feel too tired and discouraged to repeat again here. (Those who care should look the discussion up in the LKML archives.) It all smells like NIH syndrome to me (Not Invented Here). Since their solution won't be available for end-users until all the shells and PAM modules have been updated and everyone has upgraded to new distributions, I'll continue supporting the SourceForge realtime-lsm package for another year or two, as long as we still need it.

I came away dissatisfied with the whole experience. There are a number of very good Linux kernel developers, but they tend to get outshouted by a large crowd of arrogant fools. Trying to communicate user requirements to these people is a waste of time. They are much too "intelligent" to listen to lesser mortals.

On Fri, 2005-04-08 at 12:31, Jack O'Quin wrote: I have not followed the details, I presume this could be per-group, right? What are the details on how use will be controlled, if you care to comment (PAM?)? You would not have a thread url by chance?

It's a tough call because although the LSM approach clearly is more immediately user friendly, the nice and RT prio limits are a better designed solution. If your distro sets everything up right (a big if), either way it will just work.

As far as I see it, we'll at least get listened to by Con, Ingo and Andrew Morton. I've had a long discussion with Con recently and from his point of view, the problem is that not enough people ask (loud enough) for such features. For instance, I'm still the first and only user of his real-time patch.

Hi, I think a part of the conversation I had with Con Kolivas may be of interest here: <jmspeex> I still don't understand why this [unprivileged real-time] hasn't gone in the kernel a long time ago. <con> demand <con> noone demands it <con> no distro needs it <con> no market for it <con> noone coded it <con> all of the above <jmspeex> con: Everyone doing audio demands it, perhaps just no on lkml <con> jmspeex we talked about this; the developers think they know what users want <jmspeex> Just look at how many people are complaining about audio skips <con> jmspeex where? I see none <con> what audio skips? <con> find me a report anywhere that shows a properly configured 2.6 system is skipping audio even with a mainline kernel <con> the demand for real time is from the professional audio people which there are but few <jmspeex> con: Search for "xmms" and "skip", or "jackd" and "xrun" <con> ordinary desktop users get good enough low latency out of normal scheduling <con> jackd xrun != audio skipping on normal desktop usage <jmspeex> con: In my case, I needed your patch just so I could play and record at the same time on an 8-chan card. <con> aah record <con> that's not normal desktop usage <con> see what I'm getting at? <con> you're claiming it is required for ordinary audio playback <con> it is most definitely not required for ordinary audio playback <jmspeex> con: There's more people doing serious audio than you may think. <con> jmspeex ok now you're at the crux of the problem <jmspeex> Most people perhaps don't know what to do about it. <con> the crux of the problem is the potential userbase is not well known [...] <con> a tiny bit of history for you - when the realtime LSM got knocked back for the professional audio people, I stepped up and defined what they needed, and offered to create what they needed... <con> that's when I started coding up the SCHED_ISO work [...] <con> jmspeex since lkml is so hopeless as a forum for that sort of thing, feel free to start an online petition to show how many people there are. 1 of 2 things will happen - 1. you'll have thousands signing up, or 2. there are less people doing it than you think Jean-Marc Le vendredi 08 avril 2005 à 16:28 -0400, Lee Revell a écrit : >On Fri, 2005-04-08 at 16:14 -0400, Jean-Marc Valin wrote: > >>As far as I see it, we'll at least get listened to by Con, Ingo and >>Andrew Morton. I've had a long discussion with Con recently and from his >>point of view, the problem is that not enough people ask (loud enough) >>for such features. For instance, I'm still the first and only user of >>his real-time patch. > >I think many of the kernel developers have fallen into the trap of only >listening to the distros on the assumption that if enough users want >something that they'll hear from RedHat or SuSE. Clearly this is >necessary to some extent, as the distros have to filter out the >actionable bug reports, etc., and works for 99% of what users want, but >the other 1% who use a specialized distro that does not have kernel >hackers on the payroll have a hard time getting heard. > >But they will listen if people make enough noise on the mailing list. > >Lee > >

As far as I see it, we'll at least get listened to by Con, Ingo and Andrew Morton. I've had a long discussion with Con recently and from his point of view, the problem is that not enough people ask (loud enough) for such features. For instance, I'm still the first and only user of his real-time patch.

It's not just for musicians/technicians and right now there are lots of limitations that are caused by the poor unprivileged latency. Any other example?