Improving OOTB performance

[Len Ovens]

On Tue, May 22, 2012 12:31 am, óÅÒÇÅÊ äÁ×ÙÄÏ× wrote:
>> Yikes!! ulatencyd takes effect as soon as installed. Start qjackctl ok,
>> hit the start button on qjackctl... takes a long time do anything, lots
...
> Whoa, sounds like a bug. Please report at
> https://github.com/poelzi/ulatencyd/issues

I'll get there. I tried ulatency on another machine (newer) and it is ok.
Once I figure out if it will help in this situation... and how to set it
up, I'll go back to the original machine and try again.

> Also, Debian package has memory and swap management disabled by
> default, it's done via Debian-specific patch. Try enabling that and
> see if it works. Also, I don't think it has any rules for qjackctl
> OOTB, so you probably won't notice any difference.

Yes, they say "memory specific" :-)  I realize I will have to set up
rules, They have three defaults there, none of which are what we need for
audio.

In the mean time... I have been experimenting with both swappiness set to
zero and swapoff. It has been a good experience:

 Rule 1) never run unnecessary software. My test setup had swappiness 0
and jackd running silence to outputs with qjackctl to monitor for xruns
etc. I left it this way overnight (8 to 10 hours) and things seemed ok.
at the 8 hour mark there were a pile of xruns and at the 9hour or so. I
found that swap was about 50% full or so.

So I thought I would try the same thing with swap off.  I ran it over
night too, but it did not make it even to 7 hours. I found it at the logon
screen and assumed it had rebooted itself. So I logged in and noticed I
had no wireless. I checked the runlevel and found it at RL3. I have RL3
set up to stop cron and friends as well as unload the wireless driver
(ath9k) which causes an xrun per minute while loaded (or much worse) So it
was obvious that it had only logged out not booted (boots to RL2).

After some thought it occurred to me, that what I had was a memory leak
such that the cpu was killing my session with an OOM. So I watched the
memory over time and saw no problems... so it had to be happening when I
wasn't watching, my guess was the screen saver (I had set it to GLSchool),
so I set things to "blank screen only" and tried the no swap test over
again. Perfect. Even after 24 hours the memory use was very close to the
same as when I started. So I repeated the test with swap on and swappiness
to 0 again and am happy to report no swap use after 16 to 18 hours.

In the mean time I have been reading as much as I can find about swap in
Linux. (googling linux no swap gets lots) It is clear That for normal
desktop use having swap available is a good practice. That there are many
applications that ask for chunks of memory when they load that they use
only for initializing, but then never give up. That unused memory gets
paged out to swap leaving that space for other uses. My testing with
swappiness 10 seemed to agree with this assessment.

That brought me back to ulatencyd which would allow the user to decide
what would be allowed to swap out. After some thought, I am seeing a
problem with this though. I thought about what should be allowed to swap
out in an audio situation. Obviously the audio programs themselves, but I
have found that with even a quite simple recording project I run out of
screen space very quickly so I use more than one workspace and switch
between them... The screen pager just became an "audio" application...
same for the panel and the desktop background. Very quickly I was starting
to think that there are less things to allow to swap than not.

The other thing I am wondering is how the kernel swaps memory back in? How
high a priority is that? Can it be bit at a time or does each page get
done in one uninterrupted time slice? And how long does that take? In
other words would a swap in by even a low priority process cause an xrun
in my audio?

Still thinking... I am sure that the people who design swap are not
thinking RT stuff... I could be wrong.


-- 
Len Ovens
www.OvenWerks.net