Re: controlling ACPI IRQ routing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/06/2008 11:38 AM, Lee Howard wrote:
> Len Brown wrote:
>> On Wednesday 02 January 2008 09:11, Dominique Michel wrote:
>>  
>>> Le Sat, 29 Dec 2007 10:40:20 -0800,
>>> Lee Howard <faxguy@xxxxxxxxxxxxxxxx> 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.
> 
> If I boot with nolapic then XT-PIC is used, and the wcfxo device ends up
> sharing an IRQ with libata which results in worse performance than with
> it the way that it is.
> 

Try nolapic_timer ?
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux