Improving OOTB performance

[Len Ovens]

On Sun, May 13, 2012 10:36 am, Sergey \"Shnatsel\" Davidoff wrote:

> I've conducted quite a lot of performance research recently, mostly
> concerning desktop use case, but I've got some things to share about
> realtime use cases too.

Help with setting up test cases for stressing the system or normal low
latency use sets for testing would be good. It could help figure out what
configuration changes are worth doing.
>
> Ulatencyd would probably be handy for you; it's a supervisor daemon which
> prioritizes processes for resource allocation, gives some processes
> realtime privileges if needed and arranges processes in cgroups. It can
> decrease latency by smarter resource allocation and getting low-priority
> tasks out of the way of media apps. It's being tested in elementary OS
> daily builds and the results we've got so far are impressive. I'm
> currently
> working with its author on expanding default configs to accommodate more
> use cases.

It sounds interesting. I take it this uses/does something more than
prioritize irq tasklets. It could be hard to set up. We want the desktop
to still be responsive to mouse movement/clicks. I notice that with high
memory use qjackctl's gui seems to get swapped out and takes _forever_ to
redraw. (for all I know qjackctl as a whole gets swapped out)

Which brings me to a point I am just now finding out. This applies to me,
BTW, others may work differently. I have started tending to only have
applications that pertain to my current project open. That is, I don't
want any of them swapped out or their performance downgraded too much.
>
> Another useful thing would be avoiding swapping for as long as possible.
> In
> Linux there are several facilities competing for RAM - in Ubuntu's stock
> configuration executable code often gets swapped to disk to make way for
> various caches. Here's the best article I've found about it so far:
> http://rudd-o.com/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-thatMaybe
> there's something better in kernel documentation, but I'm not aware
> of that.

Setting "swappiness" helps some. but...
>
> Apart from tuning RAM allocation you can compress less important parts of
> RAM instead of swapping them to disk using zcache or zram (depending on
> what's more important for you - caches or code). I've got an overview of
> both at
> http://shnatsel.blogspot.com/2012/04/5-ideas-that-every-desktop-os-should.html

That sounds more interesting. Very much for someone like me with minimal
ram. (ram will be my next upgrade I think) One assumes
compressing/uncompressing at a slower than ram but much faster than swap
speed.

The hardest part for me has been looking at the output of "ps x" (root or
user) and figuring out what I can get rid of. (like why is there a
bluetooth daemon running if my machine has no hardware for that?)

>
> The most recent item and probably the hardest for you to implement is
> using
> a different CPU scheduler. Linux's default CFS is not a good thing for
> realtime workloads mostly because it's not designed for them. For example,
> it may very well make two realtime processes compete for accessing one CPU
> core even if there are "spare" cores availalble (according to BFS
> FAQ<http://ck.kolivas.org/patches/bfs/bfs-faq.txt>anyway). So it might
> be a good idea to look into using RIFS:
> http://www.phoronix.com/scan.php?page=news_item&px=MTEwMjQ
> Unlike I/O schedulers, changing CPU scheduler requires patching the
> kernel,
> so I doubt you'll be able to tackle it soon.

It sounds great. However, I would point out that the guys at jackd have
said that setting jackd2 to use multiple CPUs with different threads has
less than a great success. It seems that for timing sake an audio chain
needs to all be on the same cpu... at least so far. (please note that is
Len's paraphrase of what I read, check the jackd site for exactness)

>
> Hope this will be useful for you. Corrections and suggestions are always
> welcome.

Always helpful. I will have to spend time reading through it all.... and
trying it out. My big thing right now is multi-use... how can I get good
battery life most of the time but easily get great performance when I need
no xruns. I'm working on something to setup and use runlevels 2 through 5
(RL2 being stock) for different performance levels. I'm am trying to make
sure I do this in the proper way so that I don't break anything. That is
my stuff can be installed on top of vanilla ubuntu (or other debian
flavour) without breaking it and be able to be uninstalled completely as
well.

Len

-- 
Len Ovens
www.OvenWerks.net