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 al
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_
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_RT
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 Ale
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_SetThreadPrior
