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 eas
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 mechanism
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
> ass
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 thi
* 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 f
>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: sys_suspen
* 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
c
* 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 au
>(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 2.4/l
* 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 particula
* 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
>> 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
tho
* 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 mi
>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 genera
> 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 perime
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
permis
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 t
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 th
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 st
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
g
>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
>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,
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 fr
* 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 ha
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. unreque
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 someho
* 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 sta
* 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, espe
> 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
> someo
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
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, netw
[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 rlim
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 b
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 o
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 me
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 jac
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 mad
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 t
* 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
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 jac
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
* 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 theoretica
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 t
* 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
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. Jac
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 lockups
* 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:
> >> > 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 ker
* 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 unaccepta
* 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
* 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'v
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
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
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
> > s
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 w
* 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 th
* 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 ter
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:
>
> http://redhat.com/~mingo/
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 the
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:
http://redhat.com/~mingo/rt-limit-pat
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 the
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 a
75 matches
Mail list logo
