Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>> And finally, with rlimit support, is there any reason why lockup
>> detection and correction can't go into userspace? Even RT throttling
>> could probably be done in a userspace daemon.
>
> that is correct.
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>> But the important elements are lost. The standard provides a
>> deterministic scheduling order, and a deterministic scheduling latency
>> (of course this doesn't mean a great deal for Linux, but I think we're
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> And finally, with rlimit support, is there any reason why lockup
> detection and correction can't go into userspace? Even RT throttling
> could probably be done in a userspace daemon.
that is correct. Jackd already has a watchdog thread, against
* Nick Piggin [EMAIL PROTECTED] wrote:
And finally, with rlimit support, is there any reason why lockup
detection and correction can't go into userspace? Even RT throttling
could probably be done in a userspace daemon.
that is correct. Jackd already has a watchdog thread, against lockups.
Ingo Molnar [EMAIL PROTECTED] writes:
* Nick Piggin [EMAIL PROTECTED] wrote:
But the important elements are lost. The standard provides a
deterministic scheduling order, and a deterministic scheduling latency
(of course this doesn't mean a great deal for Linux, but I think we're
good enough
Ingo Molnar [EMAIL PROTECTED] writes:
* Nick Piggin [EMAIL PROTECTED] wrote:
And finally, with rlimit support, is there any reason why lockup
detection and correction can't go into userspace? Even RT throttling
could probably be done in a userspace daemon.
that is correct. Jackd already
* Jack O'Quin [EMAIL PROTECTED] wrote:
i'm wondering, couldnt Jackd solve this whole issue completely in
user-space, via a simple setuid-root wrapper app that does nothing else
but validates whether the user is in the 'jackd' group and then keeps a
pipe open to to the real jackd process
Ingo Molnar [EMAIL PROTECTED] writes:
* Jack O'Quin [EMAIL PROTECTED] wrote:
i'm wondering, couldnt Jackd solve this whole issue completely in
user-space, via a simple setuid-root wrapper app that does nothing else
but validates whether the user is in the 'jackd' group and then keeps a
* Jack O'Quin [EMAIL PROTECTED] wrote:
thus after a couple of years we'd end up with lots of desktop apps
running as SCHED_FIFO, and latency would go down the drain again.
I wonder how Mac OS X and Windows deal with this priority escalation
problem? Is it real or only theoretical?
no
At 03:01 AM 1/28/2005 -0600, Jack O'Quin wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
* Jack O'Quin [EMAIL PROTECTED] wrote:
i'm wondering, couldnt Jackd solve this whole issue completely in
user-space, via a simple setuid-root wrapper app that does nothing else
but validates whether the
Ingo Molnar wrote:
* Jack O'Quin [EMAIL PROTECTED] wrote:
i'm wondering, couldnt Jackd solve this whole issue completely in
user-space, via a simple setuid-root wrapper app that does nothing else
but validates whether the user is in the 'jackd' group and then keeps a
pipe open to to the real
* Peter Williams [EMAIL PROTECTED] wrote:
I think part of the problem here is that by comparing each tasks limit
to the runqueue's usage rate (and to some extent using a relatively
short decay period) you're creating the need for the limits to be
quite large i.e. it has to be big enough to
On Fri, 2005-01-28 at 10:11 +0100, Ingo Molnar wrote:
* Jack O'Quin [EMAIL PROTECTED] wrote:
thus after a couple of years we'd end up with lots of desktop apps
running as SCHED_FIFO, and latency would go down the drain again.
I wonder how Mac OS X and Windows deal with this priority
Peter Williams [EMAIL PROTECTED] writes:
If the average usage rate is estimated over longer periods it will be
lower allowing lower limits to be used. Also if the task's own usage
rate estimates are used to test the limits then the limit can be lower.
If the default limits can be made
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> But the important elements are lost. The standard provides a
> deterministic scheduling order, and a deterministic scheduling latency
> (of course this doesn't mean a great deal for Linux, but I think we're
> good enough for a lot of soft-rt
On Wed, 2005-01-26 at 23:15 -0600, Jack O'Quin wrote:
> >> > And finally, with rlimit support, is there any reason why lockup
> >> > detection and correction can't go into userspace? Even RT
> >> > throttling could probably be done in a userspace daemon.
> >>
> >> It can. But, doing it in the
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> Well, this extremely long discussion started with a request on behalf
> of a large group of audio developers and users for a way to gain
> realtime scheduling privileges without running as root.
>
> Several kernel developers felt that would be
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> negative nice levels are a guaranteed way to monopolize the CPU.
> SCHED_FIFO with throttling could at most be used to 'steal' CPU time
> up to the threshold. Also, if a task 'runs away' in SCHED_FIFO mode it
> will be efficiently throttled. While if
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Well in the context of a multi user system, this really is a
> privileged operation. Witness: a normal user isn't even allowed to
> raise the nice priority of a normal task. Note that I think everyone
> agrees here, but I'm just repeating the point.
* Nick Piggin [EMAIL PROTECTED] wrote:
Well in the context of a multi user system, this really is a
privileged operation. Witness: a normal user isn't even allowed to
raise the nice priority of a normal task. Note that I think everyone
agrees here, but I'm just repeating the point.
i've
* Ingo Molnar [EMAIL PROTECTED] wrote:
negative nice levels are a guaranteed way to monopolize the CPU.
SCHED_FIFO with throttling could at most be used to 'steal' CPU time
up to the threshold. Also, if a task 'runs away' in SCHED_FIFO mode it
will be efficiently throttled. While if it
* Jack O'Quin [EMAIL PROTECTED] wrote:
Well, this extremely long discussion started with a request on behalf
of a large group of audio developers and users for a way to gain
realtime scheduling privileges without running as root.
Several kernel developers felt that would be unacceptable,
On Wed, 2005-01-26 at 23:15 -0600, Jack O'Quin wrote:
And finally, with rlimit support, is there any reason why lockup
detection and correction can't go into userspace? Even RT
throttling could probably be done in a userspace daemon.
It can. But, doing it in the kernel is more
* Nick Piggin [EMAIL PROTECTED] wrote:
But the important elements are lost. The standard provides a
deterministic scheduling order, and a deterministic scheduling latency
(of course this doesn't mean a great deal for Linux, but I think we're
good enough for a lot of soft-rt applications
On Wed, 2005-01-26 at 23:15 -0600, Jack O'Quin wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > But the important elements are lost. The standard provides a
> > deterministic scheduling order, and a deterministic scheduling
> > latency
>
> Where does the standard actually say this? All
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Wed, 2005-01-26 at 20:31 -0600, Jack O'Quin wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>>
>> > I'm a bit concerned about this kind of policy and breakage of
>> > userspace APIs going into the kernel. I mean, if an app is
>> > succeeds in
On Wed, 2005-01-26 at 20:31 -0600, Jack O'Quin wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > I'm a bit concerned about this kind of policy and breakage of
> > userspace APIs going into the kernel. I mean, if an app is
> > succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
> >
Nick Piggin <[EMAIL PROTECTED]> writes:
> I'm a bit concerned about this kind of policy and breakage of
> userspace APIs going into the kernel. I mean, if an app is
> succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
> scheduler does something else, that could be undesirable in some
>
Ingo Molnar <[EMAIL PROTECTED]> writes:
> - exported the current RT-average value to /proc/stat (it's the last
>field in the cpu lines)
> e.g. the issue Con and others raised: privileged tasks. By default, the
> root user will likely have a 0 rlimit, for compatibility. _But_ i can
> easily
On Wed, 2005-01-26 at 16:27 -0600, Jack O'Quin wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > - exported the current RT-average value to /proc/stat (it's the last
> >field in the cpu lines)
>
> > e.g. the issue Con and others raised: privileged tasks. By default, the
> > root user
* Peter Williams <[EMAIL PROTECTED]> wrote:
> As I understand this (and I may be wrong), the intention is that if a
> task has its RT_CPU_RATIO rlimit set to a value greater than zero then
> setting its scheduling policy to SCHED_RR or SCHED_FIFO is allowed.
correct.
> This causes me to ask
* Peter Williams [EMAIL PROTECTED] wrote:
As I understand this (and I may be wrong), the intention is that if a
task has its RT_CPU_RATIO rlimit set to a value greater than zero then
setting its scheduling policy to SCHED_RR or SCHED_FIFO is allowed.
correct.
This causes me to ask the
On Wed, 2005-01-26 at 16:27 -0600, Jack O'Quin wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
- exported the current RT-average value to /proc/stat (it's the last
field in the cpu lines)
e.g. the issue Con and others raised: privileged tasks. By default, the
root user will likely
Ingo Molnar [EMAIL PROTECTED] writes:
- exported the current RT-average value to /proc/stat (it's the last
field in the cpu lines)
e.g. the issue Con and others raised: privileged tasks. By default, the
root user will likely have a 0 rlimit, for compatibility. _But_ i can
easily
Nick Piggin [EMAIL PROTECTED] writes:
I'm a bit concerned about this kind of policy and breakage of
userspace APIs going into the kernel. I mean, if an app is
succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
scheduler does something else, that could be undesirable in some
On Wed, 2005-01-26 at 20:31 -0600, Jack O'Quin wrote:
Nick Piggin [EMAIL PROTECTED] writes:
I'm a bit concerned about this kind of policy and breakage of
userspace APIs going into the kernel. I mean, if an app is
succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
scheduler
Nick Piggin [EMAIL PROTECTED] writes:
On Wed, 2005-01-26 at 20:31 -0600, Jack O'Quin wrote:
Nick Piggin [EMAIL PROTECTED] writes:
I'm a bit concerned about this kind of policy and breakage of
userspace APIs going into the kernel. I mean, if an app is
succeeds in gaining SCHED_FIFO /
On Wed, 2005-01-26 at 23:15 -0600, Jack O'Quin wrote:
Nick Piggin [EMAIL PROTECTED] writes:
But the important elements are lost. The standard provides a
deterministic scheduling order, and a deterministic scheduling
latency
Where does the standard actually say this? All I found was
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> > http://redhat.com/~mingo/rt-limit-patches/
> >
> > i've removed the global sysctl and implemented a new rlimit,
> > RT_CPU_RATIO: the maximum amount of CPU time RT tasks may use, in
> > percent. For testing purposes it defaults to 80%.
>
> Small
Ingo Molnar <[EMAIL PROTECTED]> writes:
> pretty much the only criticism of the RT-CPU patch was that the global
> sysctl is too rigid and that it doesnt allow privileged tasks to ignore
> the limit. I've uploaded a new RT-CPU-limit patch that solves this
> problem:
>
>
Ingo Molnar wrote:
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
http://redhat.com/~mingo/rt-limit-patches/
i've removed
Peter Williams wrote:
Ingo Molnar wrote:
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
Ingo Molnar wrote:
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
http://redhat.com/~mingo/rt-limit-patches/
i've removed
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
http://redhat.com/~mingo/rt-limit-patches/
i've removed the global sysctl
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
http://redhat.com/~mingo/rt-limit-patches/
i've removed the global sysctl
Ingo Molnar wrote:
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
http://redhat.com/~mingo/rt-limit-patches/
i've removed
Peter Williams wrote:
Ingo Molnar wrote:
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
Ingo Molnar wrote:
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
http://redhat.com/~mingo/rt-limit-patches/
i've removed
Ingo Molnar [EMAIL PROTECTED] writes:
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
* Jack O'Quin [EMAIL PROTECTED] wrote:
http://redhat.com/~mingo/rt-limit-patches/
i've removed the global sysctl and implemented a new rlimit,
RT_CPU_RATIO: the maximum amount of CPU time RT tasks may use, in
percent. For testing purposes it defaults to 80%.
Small terminology
101 - 150 of 150 matches
Mail list logo
