Re: [LAU] audio configuration for ulatencyd

On 02/15/2011 05:16 PM, torbenh wrote:

> well... your interval seems to be 500ms.

i guess you mean the delay queue here. thats a delay before a process is
even looked at, because you have so many short living processes, that
running the rules on them is just useless. It makes of course some rules
harder to implement, like cating the parent of a process as it may
already be parent of root when the delay hits...

If I implement whitelists, I will hook it into this loop so it will
circumvent it.

> thats pretty long from our POV. if a jack client is starved, it will
> generally be kicked from the graph.
> and in 500ms we are doing more than 100 processing cycles.
>
> the problem is that you can not overcommit the RT timeslices.
> so in order to have a bit of runtime in all the groups, this needs to be
> subtracted from the main RT group.
>
> and you need runtime != 0 or the thread cant obtain SCHED_FIFO in the
> first place.

One problem is, that the rt_runtime_us is not hierarchical as I
understood the problem. So when i have group a with limit 10 and two
childs with each limit 10, they both could result in 20 spent and are
not capped by the 10 limit of the parent, right ?

I'm thinking about some workarounds.
- Giving the groups a larger rt slot that is substracted from the rt group.
- Writing a simple kernel module that would move rt threads to a given
group. I saw you on the kernel mailinglist before and you seem to have
more insights then I have. Is this possible ?
- Writing a autowhitelist plugin that remembers tasks that got rt prio
before and moves them accordingly.

> of course we only set it on threads.
> it doesnt make any sense to set it on the ui threads.

Sure. Sorry to sound like a noob, i never used rt actively before :-)

> problem is that we can not bother distro maintainers to provide N
> formats of whitelists.

I'm 100% pro unified whitelist :-) As long as the format does not
contain unnecessary specifics for certain implementations and is not
that heavy to parse :-)
shall we start a wiki page, maybe on freedesktop to drop ideas and
requirements ?

> so we probably need to modify jack to do some ipc to somewhere before it acquires
> RT privileges, but this doesnt help the non jack clients.

yes, that would be great. I suggested some generic interface on the
freedesktop mailinglist as i think that a generic interface between
userspace and a system optimizer is required. Unfortunately there was
zero response...

There are a lot of potential there for all system types.

kind regards
 Daniel
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Wed Feb 16 00:15:01 2011