Ok, I just learned that X was singlethreaded. Setting it to realtime fifo,
pri 98, fixes slowing down doom 3 (which I use for testing), when moving
other windows, as that is probably due to waiting for X.
Now I wonder should RCU priority boost be at 99, or below X? Probably
above right?
And are there other threads, that X is again waiting for, that should be
above X?
Peace Be With You.
Hi.
I have made a little script, optimizing Ubuntu abit. If you have any good
and relevant information, reasonable arguments, please post them.
Do note this script is something I have quickly made, and can probably be
improved. Feedback from experienced desktop-optimizers is appreciated. The
point is to get waiting due to suboptimal policies out. Making the desktop
as responsive as it can be.
What it does for the time being, is set X to realtime, so that it`s
singlethreadedness does not become a performance bottleneck. And all
daemons to idle pri. Also idle pri, would ofcourse work best, if they are
queued in a way separately, from normal apps, so they don`t all kick in at
once. (and cause jitter)
Peace Be With You.
Please CC me.
--
#initctl list | grep running #for running daemons
echo "Setting intelligent scheduling policies."
# realtime priority for that which need it
# RCU boost to 99
sudo schedtool -p 97 -n -20 -F `pgrep X` # X is singlethreaded, this makes
it perform the best.
#does any other thread benefit(desktop) from realtime?
#for pid in `pgrep "softirqs"`; do
# sudo schedtool -F -p 98 -n -20 $pid
#done
# idle priority for daemons
for pid in `pgrep "upstart"`; do
sudo schedtool -D -p 0 -n 19 $pid
done
for pid in `pgrep "udev"`; do
sudo schedtool -D -p 0 -n 19 $pid
done
sudo schedtool -p 0 -n 19 -D `pgrep rsyslogd`
for pid in `pgrep "dbus"`; do
sudo schedtool -D -p 0 -n 19 $pid
done
sudo schedtool -p 0 -n 19 -D `pgrep modem-manager`
sudo schedtool -p 0 -n 19 -D `pgrep cupsd`
sudo schedtool -p 0 -n 19 -D `pgrep acpid`
sudo schedtool -p 0 -n 19 -D `pgrep cron`
sudo schedtool -p 0 -n 19 -D `pgrep atd`
for pid in `pgrep "avahi"`; do
sudo schedtool -D -p 0 -n 19 $pid
done
sudo schedtool -p 0 -n 19 -D `pgrep whoopsie`
for pid in `pgrep "winbindd"`; do
sudo schedtool -D -p 0 -n 19 $pid
done
sudo schedtool -p 0 -n 19 -D `pgrep polkit`
sudo schedtool -p 0 -n 19 -D `pgrep timidity`
sudo schedtool -p 0 -n 19 -D `pgrep accounts`
sudo schedtool -p 0 -n 19 -D `pgrep console`
sudo schedtool -p 0 -n 19 -D `pgrep upowerd`
sudo schedtool -p 0 -n 19 -D `pgrep colord`
sudo schedtool -p 0 -n 19 -D `pgrep rtkit` #ubuntu has set this to nice 1?
sudo schedtool -p 0 -n 19 -D `pgrep keyring`
for pid in `pgrep "gvfs"`; do
sudo schedtool -D -p 0 -n 19 $pid
done
sudo schedtool -p 0 -n 19 -D `pgrep gconf`
# remomve unneeded
#sudo stop tty6
#sudo stop tty5
#sudo stop tty4
#sudo stop tty3
#sudo stop tty2
#sudo stop tty1
#sudo modprobe -r usb-storage
sudo modprobe -r snd_seq_dummy # is anyone using this?
sudo modprobe -r snd_seq_oss
sudo modprobe -r snd_seq_midi
sudo modprobe -r snd_rawmidi
sudo modprobe -r snd_seq_midi_event
#sudo modprobe -r snd_seq
sudo modprobe -r snd_pcm_oss
sudo modprobe -r snd_mixer_oss
sudo modprobe -r serio_raw
Not many are discussing this.
So odd since an overloaded computer, looks like a computer with jitter. So
removing jitter = higher performance.
I changed X to nice -20 though instead. It is hard to predict jitter, and
maybe some measure of fairness is good.
Still daemons wouldn`t mind running sequentially as simple round robin,
or? I would like to see a lowpriority round-robin, and not just the
realtime one. Maybe a modification on "idle" pri. I just want to know
daemons can be made transparent to jitter. Or atleast some measure of
fairness to sequentialness that keeps the lowest jitter.
Anyone following ? :)
Peace Be With You.