I know there's been discussions on this before, and the only concensus reached was "use kernel 2.6.17", which apparently helps with processes that wait on pipes. There was this patch (which I tested and did have a very noticeable positive effect):
http://wiki.winehq.org/Implement_SetThreadPriority
that uses sched_setscheduler to change the scheduling policy and priority of the thread, but was rejected because it always ran privileged and allowed apps to deadlock the system if it ran a real-time thread without yielding. However, when looking at my man pages, I found this:
Since Linux 2.6.12, the RLIMIT_RTPRIO resource limit defines a ceiling on an unprivileged process's priority for the SCHED_RR and SCHED_FIFO policies. If an unprivileged process has a non-zero RLIMIT_RTPRIO soft limit, then it can change its scheduling policy and priority, subject to the restriction that the priority cannot be set to a value higher than the RLIMIT_RTPRIO soft limit. If the RLIMIT_RTPRIO soft limit is 0, then the only permitted change is to lower the priority. Subject to the same rules, another unprivileged process can also make these changes, as long as the effective user ID of the process making the change matches the real or effective user ID of the target process. See getrlimit(2) for further information on RLIMIT_RTPRIO. Privileged (CAP_SYS_NICE) processes ignore this limit; as with older older kernels, they can make arbitrary changes to scheduling policy and priority.
Meaning, if a user has their system set so that a user (or specific user(s)) have a non-zero RLIMIT_RTPRIO rlimit, normal unprivileged apps can change their scheduling policy and increase their priority up to that value; exactly what that patch does, but without needing special privileges. What would you think about implementing that patch so that it runs unprivileged, but allows the user to set their system so Wine can set time-critical thread scheduling? In this way, it would be completely up to the user if they wanted to run an app that can set real-time scheduling for cleaner audio, or not and have potential stuttering.
Or if you still don't want something like that merged in, I'd like to alert the author of that patch that it doesn't require root privs to work. It just needs a non-0 value for RLIMIT_RTPRIO (ulimit -r).
On Thu, 27 Jul 2006 02:18:49 -0700, Chris wrote:
Or if you still don't want something like that merged in, I'd like to alert the author of that patch that it doesn't require root privs to work. It just needs a non-0 value for RLIMIT_RTPRIO (ulimit -r).
Thanks for the heads up. I'll let Alexandre comment on the other stuff but I wanted the patch to work out of the box for all users, with no configuration necessary.
I don't see any way to resolve this issue satisfactorily. Windows apps require hard real time support, the kernel won't give it to us without privileged access, Alexandre doesn't want to let Windows apps do that. So it seems we lose (unless somebody conjures something that works just as well as that patch does, which so far hasn't happened).
thanks -mike
On Thursday 27 July 2006 06:10, Mike Hearn wrote:
On Thu, 27 Jul 2006 02:18:49 -0700, Chris wrote:
Or if you still don't want something like that merged in, I'd like to alert the author of that patch that it doesn't require root privs to work. It just needs a non-0 value for RLIMIT_RTPRIO (ulimit -r).
Thanks for the heads up. I'll let Alexandre comment on the other stuff but I wanted the patch to work out of the box for all users, with no configuration necessary.
It does. You don't really have to change anything. Only thing that'll happen is the setup_security function won't do anything, but the set_thread_priority funciton would still work. It's just a difference of setting the suid root bit and re-chown'ing /tmp/.wine-* all the time, or setting a non-zero RLIMIT_RTPRIO value for the user. I just think it'd be nice to let users of that patch know they don't need to run Wine with root privs if they don't want.
I don't see any way to resolve this issue satisfactorily. Windows apps require hard real time support, the kernel won't give it to us without privileged access, Alexandre doesn't want to let Windows apps do that.
I personally don't see what's wrong with letting the user decide. Without setting the suid root bit, Wine won't get any more privileges than any other Linux app run by the same user would get. Wine would just take advantage of the capabilities of a new-ish kernel feature (one that was explicitly added in, mind you; it's not a side effect or unforseen consequence) for the exact reason it was made.. to allow user space apps to get real-time priority, as defined by the user's system settings. It wouldn't be automatic, so Wine couldn't deadlock the system without the user explicitly setting the resource limit. It's exactly what Wine would need, so why not use it?
On Thu, 27 Jul 2006 15:05:12 -0700, Chris wrote:
It does. You don't really have to change anything.
I thought the user would have to change the limit in their startup scripts or the like? That isn't going to work, we need it to be fully automatic with no configuration changes needed.
RLIMIT_RTPRIO value for the user. I just think it'd be nice to let users of that patch know they don't need to run Wine with root privs if they don't want.
Sure, we should add it to the wiki page or something ...
I personally don't see what's wrong with letting the user decide. Without setting the suid root bit, Wine won't get any more privileges than any other Linux app run by the same user would get.
Well, using the suid-root bit seems more secure than this ... the limit allows any application to gain realtime privs easily whereas having wine acquire CAP_SYS_NICE means only Windows apps can get it (or rather it's very hard for other apps to use Wine to get it).
thanks -mike
On Saturday 29 July 2006 09:01, Mike Hearn wrote:
On Thu, 27 Jul 2006 15:05:12 -0700, Chris wrote:
It does. You don't really have to change anything.
I thought the user would have to change the limit in their startup scripts or the like?
I mean you don't need to change your patch at all. :) The user's going have to do something one way or the other.. either setting the suid-root bit and constantly re-chown'ing /tmp/wine-*, or setting a non-0 RLIMIT_RTPRIO value. The latter only needs to be done once, and is completely at the user's descretion at any time.
Well, using the suid-root bit seems more secure than this ... the limit allows any application to gain realtime privs easily whereas having wine acquire CAP_SYS_NICE means only Windows apps can get it (or rather it's very hard for other apps to use Wine to get it).
Though setting the suid-root bit means Windows apps will *always* be able to get realtime priority if they want, regardless of the app, whereas using the RLIMIT_RTPRIO value will let users decide, on a per-user basis, and further only when they want (running a trusted program? set it to 1 - 99 and run wine; not a trusted program? set it to 0 then run wine). Since there's different values, if another (root) process has higher priority, it's still able to interrupt the app. And if worse-comes-to-worse, there's always alt-sysrq-k.
If the goal is to match Windows feature-for-feature and bug-for-bug, this seems like a nice way to get that feature while still retaining some security. And if you're trying to blend Windows apps transparently with X apps, RLIMIT_RTPRIO is there for all apps to use on Linux.
-
Chris -
Mike Hearn