On Wednesday 02 January 2008 09:11, Dominique Michel wrote: > Le Sat, 29 Dec 2007 10:40:20 -0800, > Lee Howard <[EMAIL PROTECTED]> a écrit : > > > > # cat /proc/interrupts > > CPU0 > > 0: 1051464247 IO-APIC-edge timer > > 1: 8 IO-APIC-edge i8042 > > 8: 0 IO-APIC-edge rtc > > 9: 0 IO-APIC-fasteoi acpi > > 12: 104 IO-APIC-edge i8042 > > 14: 9414304 IO-APIC-edge ide0 > > 16: 1051172722 IO-APIC-fasteoi wct4xxp > > 19: 1 IO-APIC-fasteoi eth1 > > 21: 158008518 IO-APIC-fasteoi eth0 > > 22: 6974044 IO-APIC-fasteoi libata > > 23: 7071112 IO-APIC-fasteoi libata > > NMI: 0 > > LOC: 1051371544 > > ERR: 0 > > > > > > Based on that, you may want to use rtirq. It is a boot script (need schedutils > as dependency) with associated config scripts. http://alsa.opensrc.org/Rtirq > > In /etc/conf.d/rtirq, you will find: > > # IRQ thread service names > # (space separated list, from higher to lower priority). > RTIRQ_NAME_LIST="rtc snd usb i8042" > > The most important things is that the devices listed here doesn't have any > shared IRQ with some other device and that the rtc remain the first listed > device (the one with the higer priority), or the system will hang soon or > later. > > This setup is for audio workstation but is very easy to adapt to any kind of > work. >
I've got no experience with the thread priority thing above. However, the better way to handle quality of service contention is to not do the things you don't care about. Does the system really need HZ=1000? you could slow that down to 100, or run CONFIG_NO_HZ to reduce it even more... Also, on a UP, the LAPIC timer interrupt is redundant -- you could build your kernel w/o APIC support or boot with nolapic. This would get rid of the only interrupts which are frequent enough to be competing with the device, clock ticks. -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html