On Thu, 2005-02-03 at 22:41 +0100, Ingo Molnar wrote:
> >
> > It's clever that they do that, but additional control is needed in the
> > future. jackd isn't the most sophisticate media app on this planet (not
> > too much of an insult :)) [...]
>
> i think you are underestimating Jack - it is
On Thu, 2005-02-03 at 22:41 +0100, Ingo Molnar wrote:
It's clever that they do that, but additional control is needed in the
future. jackd isn't the most sophisticate media app on this planet (not
too much of an insult :)) [...]
i think you are underestimating Jack - it is easily
Jack O'Quin wrote:
Peter Williams <[EMAIL PROTECTED]> writes:
Paul Davis wrote:
There are several kernel-side attributes that would make JACK better
from my perspective:
* better ways to acquire and release RT scheduling
I'm no expert on the topic but it would seem to me that the
Ingo Molnar <[EMAIL PROTECTED]> writes:
> i believe RT-LSM provides a way to solve this cleanly: you can make your
> audio app setguid-audio (note: NOT setuid), and make the audio group
> have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you
> could have a finegrained per-app way of
Peter Williams <[EMAIL PROTECTED]> writes:
> Paul Davis wrote:
>> There are several kernel-side attributes that would make JACK better
>> from my perspective:
>> * better ways to acquire and release RT scheduling
>
> I'm no expert on the topic but it would seem to me that the mechanisms
>
Peter Williams [EMAIL PROTECTED] writes:
Paul Davis wrote:
There are several kernel-side attributes that would make JACK better
from my perspective:
* better ways to acquire and release RT scheduling
I'm no expert on the topic but it would seem to me that the mechanisms
associated
Ingo Molnar [EMAIL PROTECTED] writes:
i believe RT-LSM provides a way to solve this cleanly: you can make your
audio app setguid-audio (note: NOT setuid), and make the audio group
have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you
could have a finegrained per-app way of
Jack O'Quin wrote:
Peter Williams [EMAIL PROTECTED] writes:
Paul Davis wrote:
There are several kernel-side attributes that would make JACK better
from my perspective:
* better ways to acquire and release RT scheduling
I'm no expert on the topic but it would seem to me that the mechanisms
On Thu, 03 Feb 2005 21:47:11 +0100, Ingo Molnar wrote:
>
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
>
>> >* real inter-process handoff. i am thinking of something like
>> >sched_yield(), but it would take a TID as the target
>> >of the yield. this would avoid all the crap we
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> i believe RT-LSM provides a way to solve this cleanly: you can make your
> audio app setguid-audio (note: NOT setuid), and make the audio group
> have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you
> could have a finegrained per-app way of
On Thu, Feb 03, 2005 at 10:41:33PM +0100, Ingo Molnar wrote:
> * Bill Huey <[EMAIL PROTECTED]> wrote:
> > It's clever that they do that, but additional control is needed in the
> > future. jackd isn't the most sophisticate media app on this planet (not
> > too much of an insult :)) [...]
>
> i
* Paul Davis <[EMAIL PROTECTED]> wrote:
> >having this API on 2.4 kernels. But it would have one big advantage: it
> >would be evidently and trivially RT-safe :-)
>
> no small advantage.
>
> it has another big advantage from the user space perspective: no other
> information is required apart
>that might be all well and good, but i believe you still dont understand
>my point: for yield_to() to work the target task _needs to be running_.
correct, i did not understand. perhaps Con didn't either. my idea was
related to:
>in theory it would be possible to add two new syscalls:
* Paul Davis <[EMAIL PROTECTED]> wrote:
> >well, no. Unless i misunderstood your application model, you want
> >threads to sleep until they are woken up. So you want a very basic
> >sleep/wake mechanism. But yield_to() does not achieve that! yield_to()
> >will yield to _already running_ (i.e. in
Paul Davis wrote:
There are several kernel-side attributes that would make JACK better from
my perspective:
* better ways to acquire and release RT scheduling
I'm no expert on the topic but it would seem to me that the mechanisms
associated with the capable() function are intended to provide a
* Bill Huey <[EMAIL PROTECTED]> wrote:
> > but Jack is right in practical terms: the audio folks achieved pretty
> > good results with the current IRQ threading mechanism, partly due to the
> > fact that the audio stack doesnt use softirqs, so all the
> > latency-critical activities are in the
>(it would be cleaner to use POSIX semaphores for this, but you mentioned
>the requirement for the mechanism to work on 2.4 kernels too - pthread
>spinlocks will work inter-process on 2.4 too, and will schedule nicely.)
can't work. pthread interprocess spinlocks are hopelessly non-RT safe
in
* Paul Davis <[EMAIL PROTECTED]> wrote:
> however, i don't agree that futexes are conceptually superior. they
> don't express the intended operation nearly as accurately as
> yield_to(tid) would. the operation is "i have nothing else to do, and
> i want to run next". a futex says "this
* Paul Davis <[EMAIL PROTECTED]> wrote:
> Just a reminder: setuid root is precisely what we are attempting to
> avoid.
>
> >If you have the source code for the programs then they could be modified
> >to drop the root euid after they've changed policy. Or even do the
>
> This is
>> yield_to(tid) should not be too hard to implement. Ingo? What do you
>> think?
>
>i dont really like it - it's really the wrong interface to use. Futexes
>are a much better locking/signalling interface. yield_to() would not be
i agree in principle, and i was suprised to see Con express this
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> > * real inter-process handoff. i am thinking of something like
> > sched_yield(), but it would take a TID as the target
> > of the yield. this would avoid all the crap we have to
> > go through to drive the graph of clients
Paul Davis wrote:
* real inter-process handoff. i am thinking of something like
sched_yield(), but it would take a TID as the target
of the yield. this would avoid all the crap we have to
go through to drive the graph of clients with FIFO's and
write(2) and poll(2). Futexes
>This is a bit off topic, but I'm interested in applications that are
>more driven by time and has abstraction closer to that in a pure way.
>A lot of audio kits tend to be overly about DSP and not about time.
>This is difficult to explain, but what I'm referring to here is ideally
>the next
This is a bit off topic, but I'm interested in applications that are
more driven by time and has abstraction closer to that in a pure way.
A lot of audio kits tend to be overly about DSP and not about time.
This is difficult to explain, but what I'm referring to here is ideally
the next generation
Paul Davis wrote:
* real inter-process handoff. i am thinking of something like
sched_yield(), but it would take a TID as the target
of the yield. this would avoid all the crap we have to
go through to drive the graph of clients with FIFO's and
write(2) and poll(2). Futexes
* Con Kolivas [EMAIL PROTECTED] wrote:
* real inter-process handoff. i am thinking of something like
sched_yield(), but it would take a TID as the target
of the yield. this would avoid all the crap we have to
go through to drive the graph of clients with
yield_to(tid) should not be too hard to implement. Ingo? What do you
think?
i dont really like it - it's really the wrong interface to use. Futexes
are a much better locking/signalling interface. yield_to() would not be
i agree in principle, and i was suprised to see Con express this
thought
* Paul Davis [EMAIL PROTECTED] wrote:
Just a reminder: setuid root is precisely what we are attempting to
avoid.
If you have the source code for the programs then they could be modified
to drop the root euid after they've changed policy. Or even do the
This is insufficient, since
* Paul Davis [EMAIL PROTECTED] wrote:
however, i don't agree that futexes are conceptually superior. they
don't express the intended operation nearly as accurately as
yield_to(tid) would. the operation is i have nothing else to do, and
i want tid to run next. a futex says this particular
(it would be cleaner to use POSIX semaphores for this, but you mentioned
the requirement for the mechanism to work on 2.4 kernels too - pthread
spinlocks will work inter-process on 2.4 too, and will schedule nicely.)
can't work. pthread interprocess spinlocks are hopelessly non-RT safe
in
* Bill Huey [EMAIL PROTECTED] wrote:
but Jack is right in practical terms: the audio folks achieved pretty
good results with the current IRQ threading mechanism, partly due to the
fact that the audio stack doesnt use softirqs, so all the
latency-critical activities are in the audio IRQ
Paul Davis wrote:
There are several kernel-side attributes that would make JACK better from
my perspective:
* better ways to acquire and release RT scheduling
I'm no expert on the topic but it would seem to me that the mechanisms
associated with the capable() function are intended to provide a
* Paul Davis [EMAIL PROTECTED] wrote:
well, no. Unless i misunderstood your application model, you want
threads to sleep until they are woken up. So you want a very basic
sleep/wake mechanism. But yield_to() does not achieve that! yield_to()
will yield to _already running_ (i.e. in the
that might be all well and good, but i believe you still dont understand
my point: for yield_to() to work the target task _needs to be running_.
correct, i did not understand. perhaps Con didn't either. my idea was
related to:
in theory it would be possible to add two new syscalls:
* Paul Davis [EMAIL PROTECTED] wrote:
having this API on 2.4 kernels. But it would have one big advantage: it
would be evidently and trivially RT-safe :-)
no small advantage.
it has another big advantage from the user space perspective: no other
information is required apart from tid.
On Thu, Feb 03, 2005 at 10:41:33PM +0100, Ingo Molnar wrote:
* Bill Huey [EMAIL PROTECTED] wrote:
It's clever that they do that, but additional control is needed in the
future. jackd isn't the most sophisticate media app on this planet (not
too much of an insult :)) [...]
i think you are
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
i believe RT-LSM provides a way to solve this cleanly: you can make your
audio app setguid-audio (note: NOT setuid), and make the audio group
have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you
could have a finegrained per-app way of
On Thu, 03 Feb 2005 21:47:11 +0100, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
* real inter-process handoff. i am thinking of something like
sched_yield(), but it would take a TID as the target
of the yield. this would avoid all the crap we have to
> Jack O'Quin wrote:
>> Temporarily dropping privileges gains no security whatsoever. It is
>> nothing more than a coding convenience.
Peter Williams <[EMAIL PROTECTED]> writes:
> Yes, to help avoid accidentally misusing the privileges.
>> The program remains *inside* the system security
Bill Huey (hui) wrote:
On Thu, Feb 03, 2005 at 08:54:24AM +1100, Peter Williams wrote:
As Ingo said in an earlier a post, with a little ingenuity this problem
can be solved in user space. The programs in question can be setuid
root so that they can set RT scheduling policy BUT have their
Jack O'Quin wrote:
Peter Williams <[EMAIL PROTECTED]> writes:
If you have the source code for the programs then they could be
modified to drop the root euid after they've changed policy. Or
even do the
Paul Davis wrote:
This is insufficient, since they need to be able to drop RT
scheduling and
On Thu, Feb 03, 2005 at 08:54:24AM +1100, Peter Williams wrote:
> As Ingo said in an earlier a post, with a little ingenuity this problem
> can be solved in user space. The programs in question can be setuid
> root so that they can set RT scheduling policy BUT have their
> permissions set so
On Wed, Feb 02, 2005 at 05:59:54PM -0500, Paul Davis wrote:
> Actually, JACK probably is the most sophisticated media *framework* on
> the planet, at least inasmuch as it connects ideas drawn from the
> media world and OS research/design into a coherent package. Its not
> perfect, and we've just
Peter Williams <[EMAIL PROTECTED]> writes:
>>> If you have the source code for the programs then they could be
>>> modified to drop the root euid after they've changed policy. Or
>>> even do the
> Paul Davis wrote:
>> This is insufficient, since they need to be able to drop RT
>> scheduling and
Paul Davis wrote:
As Ingo said in an earlier a post, with a little ingenuity this problem
can be solved in user space. The programs in question can be setuid
root so that they can set RT scheduling policy BUT have their
permissions set so that they only executable by owner and group with the
>As Ingo said in an earlier a post, with a little ingenuity this problem
>can be solved in user space. The programs in question can be setuid
>root so that they can set RT scheduling policy BUT have their
>permissions set so that they only executable by owner and group with the
>group set to
>It's clever that they do that, but additional control is needed in the
>future. jackd isn't the most sophisticate media app on this planet (not
>too much of an insult :)) and the demands from this group is bound to
Actually, JACK probably is the most sophisticated media *framework* on
the
Ingo Molnar <[EMAIL PROTECTED]> writes:
> so forgive us this stubborness, it's not directed against you in person
> or against any group of users, it's always directed at the problem at
> hand. I think we can do the LSM thing, and if this problem comes up in
> the future again, then maybe by that
On Wed, Feb 02, 2005 at 01:14:05PM -0800, Bill Huey wrote:
> Step one in this is to acknowlege that Unix scheduling semantics is
> "inantiquated" with regard to media apps. Some notion of scoping needs to
bah, "inadequate".
> be put in.
>
> Everybody on the same page ?
bill
-
To unsubscribe
* Bill Huey <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 02, 2005 at 10:44:22AM -0600, Jack O'Quin wrote:
> > I believe Ingo's RT patches already support this on a per-IRQ basis.
> > Each IRQ handler can run in a realtime thread with priority assigned
> > by the sysadmin. Balancing the interrupt
Bill Huey (hui) wrote:
On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote:
Ingo Molnar <[EMAIL PROTECTED]> writes:
(also, believe me, this is not arrogance or some kind of game on our
part. If there was a nice clean solution that solved your and others'
problems equally well then it would
On Wed, Feb 02, 2005 at 10:21:00PM +0100, Ingo Molnar wrote:
> yes and no. You are right in that the individual workloads (e.g.
> softirqs) are not separated and identified/credited to the thread that
> requested them. (in part due to the fact that you cannot e.g. credit a
> thread for e.g.
On Wed, Feb 02, 2005 at 10:44:22AM -0600, Jack O'Quin wrote:
> Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> > Also, as media apps get more sophisticated they're going to need some
> > kind of access to the some traditional softirq facilities, possibily
> > migrating it into userspace safely
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> I guess you're right, Lee. I hadn't thought of it that way. It just
> looks broken to me because we have no standing in any normal kernel
> requirements process. That's a shame, but it does seem less like a
> systemic issue.
you have just as much
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> The LSM was a stop-gap measure intended to tide us over until a real
> fix could be "done right" for 2.8. It had the advantage of being
> minimally disruptive to the kernel and its maintainability. [...]
i'm not opposed to the LSM solution per se,
> On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote:
>> Is nobody responsible for figuring out what users need? I didn't
>> realize kernel development had become so disconnected.
Lee Revell <[EMAIL PROTECTED]> writes:
> IMHO the requirements gathering process usually works well. When
>
On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote:
> > So in the Linux core code we have zero tolerance on crap. We are
> > doing this for the long-term fun of it.
>
> So, we should never do anything boring, even though people actually
> need it?
>
> The fact that a large group of
Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> Also, as media apps get more sophisticated they're going to need some
> kind of access to the some traditional softirq facilities, possibily
> migrating it into userspace safely somehow, with how it handles IO
> processing such as iSCSI, FireWire,
[trimming the Cc: list]
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>> Remember when I asked how you handle changes to sizeof(struct rusage)?
>> That was a serious question. I hope there's a solution. [...]
Ingo Molnar <[EMAIL PROTECTED]> writes:
> what does any of what we've talking about have
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> Remember when I asked how you handle changes to sizeof(struct rusage)?
> That was a serious question. I hope there's a solution. [...]
what does any of what we've talking about have to do with struct rusage?
One of the patches i wrote adds a new
On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
> > (also, believe me, this is not arrogance or some kind of game on our
> > part. If there was a nice clean solution that solved your and others'
> > problems equally well then it would already
On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
(also, believe me, this is not arrogance or some kind of game on our
part. If there was a nice clean solution that solved your and others'
problems equally well then it would already be in
* Jack O'Quin [EMAIL PROTECTED] wrote:
Remember when I asked how you handle changes to sizeof(struct rusage)?
That was a serious question. I hope there's a solution. [...]
what does any of what we've talking about have to do with struct rusage?
One of the patches i wrote adds a new rlimit.
[trimming the Cc: list]
* Jack O'Quin [EMAIL PROTECTED] wrote:
Remember when I asked how you handle changes to sizeof(struct rusage)?
That was a serious question. I hope there's a solution. [...]
Ingo Molnar [EMAIL PROTECTED] writes:
what does any of what we've talking about have to do
Bill Huey (hui) [EMAIL PROTECTED] writes:
Also, as media apps get more sophisticated they're going to need some
kind of access to the some traditional softirq facilities, possibily
migrating it into userspace safely somehow, with how it handles IO
processing such as iSCSI, FireWire,
On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote:
So in the Linux core code we have zero tolerance on crap. We are
doing this for the long-term fun of it.
So, we should never do anything boring, even though people actually
need it?
The fact that a large group of frustrated Linux
On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote:
Is nobody responsible for figuring out what users need? I didn't
realize kernel development had become so disconnected.
Lee Revell [EMAIL PROTECTED] writes:
IMHO the requirements gathering process usually works well. When
someone with
* Jack O'Quin [EMAIL PROTECTED] wrote:
The LSM was a stop-gap measure intended to tide us over until a real
fix could be done right for 2.8. It had the advantage of being
minimally disruptive to the kernel and its maintainability. [...]
i'm not opposed to the LSM solution per se, especially
* Jack O'Quin [EMAIL PROTECTED] wrote:
I guess you're right, Lee. I hadn't thought of it that way. It just
looks broken to me because we have no standing in any normal kernel
requirements process. That's a shame, but it does seem less like a
systemic issue.
you have just as much
On Wed, Feb 02, 2005 at 10:44:22AM -0600, Jack O'Quin wrote:
Bill Huey (hui) [EMAIL PROTECTED] writes:
Also, as media apps get more sophisticated they're going to need some
kind of access to the some traditional softirq facilities, possibily
migrating it into userspace safely somehow, with
On Wed, Feb 02, 2005 at 10:21:00PM +0100, Ingo Molnar wrote:
yes and no. You are right in that the individual workloads (e.g.
softirqs) are not separated and identified/credited to the thread that
requested them. (in part due to the fact that you cannot e.g. credit a
thread for e.g.
Bill Huey (hui) wrote:
On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
(also, believe me, this is not arrogance or some kind of game on our
part. If there was a nice clean solution that solved your and others'
problems equally well then it would
* Bill Huey [EMAIL PROTECTED] wrote:
On Wed, Feb 02, 2005 at 10:44:22AM -0600, Jack O'Quin wrote:
I believe Ingo's RT patches already support this on a per-IRQ basis.
Each IRQ handler can run in a realtime thread with priority assigned
by the sysadmin. Balancing the interrupt handler
On Wed, Feb 02, 2005 at 01:14:05PM -0800, Bill Huey wrote:
Step one in this is to acknowlege that Unix scheduling semantics is
inantiquated with regard to media apps. Some notion of scoping needs to
bah, inadequate.
be put in.
Everybody on the same page ?
bill
-
To unsubscribe from this
Ingo Molnar [EMAIL PROTECTED] writes:
so forgive us this stubborness, it's not directed against you in person
or against any group of users, it's always directed at the problem at
hand. I think we can do the LSM thing, and if this problem comes up in
the future again, then maybe by that time
It's clever that they do that, but additional control is needed in the
future. jackd isn't the most sophisticate media app on this planet (not
too much of an insult :)) and the demands from this group is bound to
Actually, JACK probably is the most sophisticated media *framework* on
the planet,
As Ingo said in an earlier a post, with a little ingenuity this problem
can be solved in user space. The programs in question can be setuid
root so that they can set RT scheduling policy BUT have their
permissions set so that they only executable by owner and group with the
group set to a
Paul Davis wrote:
As Ingo said in an earlier a post, with a little ingenuity this problem
can be solved in user space. The programs in question can be setuid
root so that they can set RT scheduling policy BUT have their
permissions set so that they only executable by owner and group with the
Peter Williams [EMAIL PROTECTED] writes:
If you have the source code for the programs then they could be
modified to drop the root euid after they've changed policy. Or
even do the
Paul Davis wrote:
This is insufficient, since they need to be able to drop RT
scheduling and then reacquire
On Wed, Feb 02, 2005 at 05:59:54PM -0500, Paul Davis wrote:
Actually, JACK probably is the most sophisticated media *framework* on
the planet, at least inasmuch as it connects ideas drawn from the
media world and OS research/design into a coherent package. Its not
perfect, and we've just
On Thu, Feb 03, 2005 at 08:54:24AM +1100, Peter Williams wrote:
As Ingo said in an earlier a post, with a little ingenuity this problem
can be solved in user space. The programs in question can be setuid
root so that they can set RT scheduling policy BUT have their
permissions set so that
Jack O'Quin wrote:
Peter Williams [EMAIL PROTECTED] writes:
If you have the source code for the programs then they could be
modified to drop the root euid after they've changed policy. Or
even do the
Paul Davis wrote:
This is insufficient, since they need to be able to drop RT
scheduling and
Bill Huey (hui) wrote:
On Thu, Feb 03, 2005 at 08:54:24AM +1100, Peter Williams wrote:
As Ingo said in an earlier a post, with a little ingenuity this problem
can be solved in user space. The programs in question can be setuid
root so that they can set RT scheduling policy BUT have their
Jack O'Quin wrote:
Temporarily dropping privileges gains no security whatsoever. It is
nothing more than a coding convenience.
Peter Williams [EMAIL PROTECTED] writes:
Yes, to help avoid accidentally misusing the privileges.
The program remains *inside* the system security perimeter.
Ingo,
I hope we can get past this anger and continue working together. We
have too much to gain by cooperating. It would be a shame to let hurt
feelings get in the way for either of us.
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>> Well, this extremely long discussion started with a request
Ingo,
I hope we can get past this anger and continue working together. We
have too much to gain by cooperating. It would be a shame to let hurt
feelings get in the way for either of us.
* Jack O'Quin [EMAIL PROTECTED] wrote:
Well, this extremely long discussion started with a request on
On Mon, Jan 31, 2005 at 05:29:10PM -0500, Bill Davidsen wrote:
> The problem hasn't changed in a few decades, neither has the urge of
> developers to make their app look good at the expense of the rest of the
> system. Been there and done that myself.
>
> "Back when" we had no good tools except
Ingo Molnar wrote:
* 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
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
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
Ingo Molnar wrote:
* 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
On Mon, Jan 31, 2005 at 05:29:10PM -0500, Bill Davidsen wrote:
The problem hasn't changed in a few decades, neither has the urge of
developers to make their app look good at the expense of the rest of the
system. Been there and done that myself.
Back when we had no good tools except to
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
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
* 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
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
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
* 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
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
* 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
1 - 100 of 150 matches
Mail list logo
