Possible tricks for OS?

Getting Stuff Done Hints and Tricks
#1

With all the things that a multi-tasking operating system does, I wonder if the conversation has been beating (like a dead horse) or if there are some common sense things to turn off (and change/tweak) during Ardour+Jack usage?

What got me thinking about this was coming across the swappiness setting inside /proc [http://kerneltrap.org/node/3000] and further got to thinking. I think I tinkered around with disabling cron from running (don’t seem to make sense to possibly launch something that might increase disk usage unexpectedly).

The main thing is disk usage should be focused on reading/writing disk I/O first and foremost. Swap space on a decent machine is normally kept to a minimum, but it’s impact (if on same storage path) could be undesired. The two schools of thought would be have lots of RAM and disable swap partition -OR- you should always have a swap file. For disk based audio processing, and systems that have swap. It seems that setting the swappiness (/prov/sys/vm/swappiness) lower than default 60 (less aggressive at swapping out code space to disk) translates to less disk caching. Flip side, too high and you have code swapped out to disk more so.

I wish I could assume that ALL (important) loaded code that could escalate to blocking RT sensitive code would be locked [mlock()] and thus would only block under from something NOT related to being swapped back from disk. I am sure that code that is active and not locked is tracked via performance counters and passed over for swapping.

It’s a balancing game, disk caching can only help so far and can’t continuously make a particular drive behave faster (only in limited ways).

I figure that disabling cron and perhaps a few other things (I can’t think of any at the moment) and perhaps lowering swappiness to 1/2 (30 instead of 60) is probably a safe bet.

A good system would have a dedicated system+swap drive and separate storage path (drive is a must, cable, controller/interface if possible) for audio and plenty of RAM and have as many intermittent background tasks disabled.

Oh well, perhaps I am over thinking – several articles on swappiness got me thinking about it within Ardour+Jack context.

Any comments? Anyone? Anyone? Bueller… Bueller…

–Doug

#2

If JACK is running in realtime mode, all memory of the server and all clients is mlocked (though JACK will try to unlock stuff obviously related to GUI libraries on the grounds that it should never run in an RT thread).

#3

Ah… I think you said something that I’ll try to translate (that others might have missed)! It sounds like you WANT to avoid running things w/ RT privileges that should never need it (GTK/GUI routines). That answers another outstanding question I had.

My thinking in doing a “chrt 1 ardour2” would be that ardour’s UI would have drawing priority over other non-RT GUI tasks but lower priority over the RT priorities you (hopefully) set higher than 1.

If I read you correctly, this is possibly an undesired thing. A GUI routine could make a call to (say) X server and get blocked at hardware level, but that same code (RT or NOT) would still be preempted by higher priority code (core JACK stuff) in theory. Perhaps a toss up if done correctly. Only (minor) advantage is Ardour2’s GUI could be a little bit more responsive over other GUI code… perhaps not.

(above was off of topic), saying that all memory is locked sounds like JACK performs the memory locking (I haven’t looked at the code so I am guessing).

The flip side question, RT audio code and buffers are locked as-well-as GUI code is unlocked (and non-rt) and COULD be swapped out… I guess better stated, the remaining memory, is it better used for disk caching or code? Where should that line rest?

–Doug (dx9s)