Poor performance (unresponsive, pausing, stuttering etc.)

[Fitzcarraldo]

Is it not easier to run something similar to "renice" as we used in OSX and then fine tune some of the configs for this to get a bit more speed.

http://www.oreillynet.com/linux/cmd/cmd ... h=r/renice

Niceness won't do the job because the stock SL 2.6.26 kernel has the CFS Scheduler configured as follows:

Code: Select all

CONFIG_FAIR_GROUP_SCHED=y
CONFIG_USER_SCHED=y

CONFIG_USER_SCHED means that tasks are grouped according to their user id, and niceness only applies within a group. If there are, say, two users "fitzcarraldo" and "herzog", the CFS Scheduler gives 50% of the CPU 'bandwidth' to fitzcarraldo and 50% to herzog. So if the task mplayer runs under user fitzcarraldo and the task updatedb runs under herzog, and you want mplayer to get a bigger share of the CPU, reducing its niceness will not stop herzog getting 50% of the CPU bandwidth. The only way you could use niceness to boost one of two tasks relative to the other would be to put them both in the fitzcarraldo group or both in the herzog group. If the two tasks are in separate groups then you would have to allocate a smaller CPU bandwidth to herzog. But that will affect all tasks run by herzog. To find out the cpu_share allocated to each user you would enter:

Code: Select all

# cat /sys/kernel/uids/'id -u fitzcarraldo'/cpu_share
# cat /sys/kernel/uids/'id -u herzog'/cpu_share

and to reduce herzog's CPU bandwith allocation you would type:

Code: Select all

echo <n> > /sys/kernel/<uid of herzog>/cpu_share

where <n> is a smaller number than the number in cpu_share for user fitzcarraldo. I stress that the above relates to the case when CONFIG_FAIR_GROUP_SCHED plus CONFIG_USER_SCHED have been selected in the kernel config, which is the case in the stock SL 2.6.26 kernel.

If, instead, CONFIG_FAIR_GROUP_SCHED plus CONFIG_CGROUP_SCHED have been selected in the kernel config, which is what I did (see my earlier post), then the above-mentioned directories /sys/kernel/<uid>/cpu_share don't even exist. Instead one has to use the "cgroups" pseudo filesystem and create task groups, and adjust the value in a cpu.shares file created per group (see my earlier post):

Code: Select all

# mkdir /dev/cpuctl
# mount -t cgroup -ocpu none /dev/cpuctl
# cd /dev/cpuctl
# mkdir multimedia <--- create a group for your higher-priority tasks
# mkdir browser  <--- create a group for your lower-priority tasks
# cat multimedia/cpu.shares
1024
# cat browser/cpu.shares
1024
# echo 2048 > multimedia/cpu.shares <--- give group "multimedia" higher CPU bandwidth than group "browser"
# echo <firefox_pid> > browser/tasks
# echo <mplayer_pid> > multimedia/tasks

Changing the niceness of mplayer would only change its niceness relative to the niceness of the other tasks in the same group ("multimedia").

Anyway, this is my understanding of it all after a week surfing the Web and breaking my head.

[gforum]

hey fitz im not really an expert on teh subject, but i did notice something.
i have basically a copy of your hardware, except that my card is a nvidia 8600m GT 512mb, and i never got anything like what you did, and i push my system around all the time, but it just flies...

so my guess is that maybe in a combo of(and between) the AMD radeon drivers, and the non-stellar kernel scheduling issues, you get your stuttering.
id give it a try, n' go on a pc with a nvidia card(with similar specs), and see for yourself what gives...

but, to my humble knowledge, as of right now this problem is rather insane.
maybe, if it is diagnosed that the gpu does have to do with it, then it goes from crazy, to expected, given amd's long standing posture(ignoring linux).

maybe this is nothing, but it might help.

cheers.

ps: oh and btw, congrats on the 'workaround'.

[Fitzcarraldo]

^AMD (ATI) has improved a lot over the last 18 months, and seems to bring out a new version of the fglrx driver almost monthly but, yes, I do realise that the pausing problem could be due to the AMD Catalyst driver (fglrx), as I mentioned in a couple of previous posts. I'm listening to music using Amarok as I type this and, even under Compiz-Fusion, there is absolutely no stuttering or pausing of the music if I drag windows, drag window sliders up and down fast, maximise windows, run applications concurrently, and so on. So that might point to the video driver. The AMD Catalyst 8.10 (2008.October) driver is due out this month, so I'll see if there are any improvements with that, especially if it will work with xorg-7.4 and xorg-server-1.5.0 as has been mooted.


Just to recap the various tuning settings that are staying on my laptop as they have either not had a negative effect or have actually helped noticeably:

1. Add "nmi_watchdog=0 elevator=as nopat" to the kernel boot line in /boot/grub/grub.conf:

Code: Select all

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,2)
#          kernel /kernel-genkernel real_root=UUID=6c2e8b37-21cb-4d0f-9ef9-e47598fe1763
#          initrd /initramfs-genkernel
#boot=sda3
default=0
timeout=10
splashimage=(hd0,2)/grub/splash.xpm.gz
password --md5 $2$kn1Lj$e/5SNtgA.QQHmffXo9aat0
#
title=Sabayon Linux x86_64 (2.6.26-sabayon)
        root (hd0,2)
        kernel /kernel-genkernel-x86_64-2.6.26-sabayon  root=/dev/ram0 ramdisk=8192 real_root=UUID=6c2e8b37-21cb-4d0f-9ef9-e47598fe1763  quiet  init=/linuxrc splash=silent,theme:sabayon vga=791 CONSOLE=/dev/tty1 pci=nomsi nmi_watchdog=0 elevator=as nopat
        initrd /initramfs-genkernel-x86_64-2.6.26-sabayon
#
title=Sabayon Linux x86_64 (2.6.25-sabayon-r1)
        root (hd0,2)
        kernel /kernel-genkernel-x86_64-2.6.25-sabayon-r1  root=/dev/ram0 ramdisk=8192 real_root=UUID=6c2e8b37-21cb-4d0f-9ef9-e47598fe1763  quiet  init=/linuxrc splash=silent,theme:sabayon vga=791 CONSOLE=/dev/tty1 pci=nomsi
        initrd /initramfs-genkernel-x86_64-2.6.25-sabayon-r1
#
title Windows XP
        rootnoverify (hd0,1)
        chainloader +1

Changing from the CFQ I/O scheduler (the default in the SL 2.6.26 kernel) to the Anticipatory I/O scheduler (adding "elevator=as" in grub.conf) was a noticeable improvement, as was adding the "nopat" boot option in grub.conf. These got rid of the stuttering (specifically) in videos in my case.


2. Add "commit=60,noatime,nodiratime" to fstab:

Code: Select all

/dev/disk/by-uuid/6c2e8b37-21cb-4d0f-9ef9-e47598fe1763  /                       ext3    user_xattr,commit=60,noatime,nodiratime      1 1
/dev/disk/by-uuid/9595b455-5d2b-4fe4-9933-8a23fdbd15d9  /home                   ext3    user_xattr,commit=60,noatime,nodiratime      1 2
/dev/disk/by-uuid/3d0f2274-eb88-4da1-804a-e0638def51ec  /boot                   ext3    user_xattr,commit=60,noatime,nodiratime      1 2
/dev/shm                                                /dev/shm                tmpfs   defaults        0 0
/dev/disk/by-uuid/c74eb297-4381-4eb5-a279-d451c049de88  swap                    swap    defaults        0 0


This addition resulted in faster disk access in my case.


3. Use CONFIG_CGROUPS_SCHED instead of CONFIG_USER_SCHED in the General Setup section of the kernel:

Code: Select all

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_USER_SCHED is not set
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_MM_OWNER=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
# CONFIG_HAVE_DMA_ATTRS is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLOCK_COMPAT=y

This has no negative impact if you do nothing after rebuilding the kernel, but allows you to set up "control groups" (cgroups) and allocate them different CPU bandwidths for the CFS Scheduler.


4. Turn on CONFIG_SCHED_DEBUG in the Kernel Hacking section of the kernel:

Code: Select all

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_NONPROMISC_DEVMEM=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DIRECT_GBPAGES is not set
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_X86_MPPARSE=y
# CONFIG_IOMMU_DEBUG is not set
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set

This enables you to tune the CFS Scheduler -- and many other things -- using echo or sysctl.

[Fitzcarraldo]

I'm afraid that I've found the opposite. 3.5 x86-64 for me gives better performance than 3.4f did. My system is not fully updated as I have stuck with kernel 2.6.25-r1 (I have the latest kernel installed but am just waiting for the opportunity to do the necessary work on my nvidia drivers) but all other packages are fully up to date. I hesitate to say this (think of granny and sucking eggs!) but I wouldn't pass up the opportunity of a fresh install of a distro and wonder if your problem is because you just kept updating 3.4f rather than doing a fresh install.

Just to put to rest the idea that a fresh install of SL 3.5 would have been better than using an earlier installation that had been brought up to date using rolling updates, I formatted all my partitions and installed SL 3.5 from the LiveDVD. The performance is the same as before. I have therefore applied the same changes to grub.conf and fstab that I applied previously. Thus I was correct in believing that there was nothing wrong with my installation, which I had kept bang up to date (more so than SL 3.5, in fact) by rolling updates using Portage.

Throwing away my SL installation of 9 months to try this experiment may seem drastic, but I intend to install from scratch anyway when SL 4.0 comes out. The downside is that now I will have to bring the fresh SL 3.5 install back up to the level I had before, if I can be bothered.

Just as an aside, I ran 3.4e quite happily without a swap (despite Wolfden's warning) and am tempted to turn it off here just to see what will happen. I know the process is different in XP, but I always ran that without a swap file and found better performance.

I forgot to mention previously that I tried turning off swap to see what happened. Since the swap partition was virtually never used, as expected it made no difference.

[dunsurfin]

Just to put to rest the idea that a fresh install of SL 3.5 would have been better than using an earlier installation that had been brought up to date using rolling updates, I formatted all my partitions and installed SL 3.5 from the LiveDVD. The performance is the same as before. I have therefore applied the same changes to grub.conf and fstab that I applied previously. Thus I was correct in believing that there was nothing wrong with my installation, which I had kept bang up to date (more so than SL 3.5, in fact) by rolling updates using Portage.

Throwing away my SL installation of 9 months to try this experiment may seem drastic, but I intend to install from scratch anyway when SL 4.0 comes out. The downside is that now I will have to bring the fresh SL 3.5 install back up to the level I had before, if I can be bothered.

Such dedication! As it was a fresh install of 3.5, you will now be using the 2.6.25 kernel which suggests that it's not the 2.6.26 kernel which is the cause of your poor performance.

[dunsurfin]

Here's a totally over the top suggestion (since you are waiting for 4.0 to come out). Try fresh installs of 3.4 or 3.3 to see if the performance issues are still there.

[Fitzcarraldo]

Actually, I did consider doing that too, but I threw away my LiveDVDs for 3.26, 3.3 and 3.4 a few months ago.

[dunsurfin]

I do have 3.3 (86-64) and 3.4e (86-64) if you wanted a copy.

[Fitzcarraldo]

Thanks for the offer, but my HDD is currently thrashing away with the Entropy updates and I don't want to have to go through it all again. I have never used Entropy/Equo/Spritz so I thought I'd use this fresh install as an opportunity to play around with it for a while, although it's my intention to go back to Portage when/if I install SL 4.0.

[dunsurfin]

Thanks for the offer, but my HDD is currently thrashing away with the Entropy updates and I don't want to have to go through it all again. I have never used Entropy/Equo/Spritz so I thought I'd use this fresh install as an opportunity to play around with it for a while,

Have fun!