- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i am not sure this is the right place to discuss this, yet i'm looking for possible pointers that can lead me to the right direction.
if i do
nass@stargaze:~$ cat /proc/interrupts
CPU0 CPU1
0: 1764867489 0 IO-APIC-edge timer
1: 13418 0 IO-APIC-edge i8042
4: 130276577 0 IO-APIC-edge serial
6: 3 0 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 3 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 381820 0 IO-APIC-edge i8042
16: 238 0 IO-APIC-fasteoi ohci1394, ehci_hcd:usb1, libata, uhci_hcd:usb7
17: 539010173 0 IO-APIC-fasteoi uhci_hcd:usb3, nvidia
18: 0 0 IO-APIC-fasteoi libata
19: 185580186 0 IO-APIC-fasteoi uhci_hcd:usb6, eth0
20: 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
22: 239687 0 IO-APIC-fasteoi HDA Intel
23: 6502 0 IO-APIC-fasteoi ide2, ide3
219: 32516511 0 PCI-MSI-edge libata
NMI: 0 0
LOC: 1748160692 1748160694
ERR: 0
MIS: 0
it is apparent to me that the 2nd cpu of my core 2 duo does not handle interrupts (apart from the LOC - what is this ? ).
also i am under the impression that the 2nd cpu is used less altogether since when i check the KGuard system monitor, i usually see one processor usage varying at 0-85%, and the other only at 0-4%...
any ideas how i could fix that?
thank you in advance for your help
Nass
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
however, i used this guide http://gentoo-wiki.com/HARDWARE_Intel_Core2_Duo to create a kernel with the options for the 32bit core 2 duo processor and now i get
nass@stargaze:~$ cat /proc/interrupts
CPU0 CPU1
0: 3265 954119 IO-APIC-edge timer
1: 38 0 IO-APIC-edge i8042
4: 64630 0 IO-APIC-edge serial
6: 3 0 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 3 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 196 0 IO-APIC-edge i8042
16: 50 0 IO-APIC-fasteoi ohci1394, ehci_hcd:usb1, ide0, uhci_hcd:usb7
17: 267656 0 IO-APIC-fasteoi uhci_hcd:usb3, nvidia
18: 0 0 IO-APIC-fasteoi libata
19: 3420585 3417181 IO-APIC-fasteoi uhci_hcd:usb6, eth0
20: 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5
21: 3037 1494 IO-APIC-fasteoi ide2, ide3
22: 0 0 IO-APIC-fa steoi uhci_hcd:usb4
23: 167 0 IO-APIC-fasteoi HDA Intel
219: 43196 20717 PCI-MSI-edge libata
NMI: 0 0
LOC: 944350 944349
ERR: 0
MIS: 0
it seems far more meaningful...no? :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Multi-threaded interrupt handling would likely yield poorer performance.
Interrupt handling is a very small portion of code (or at least it should be if programmed correctly). The typical interrupt code is to acknowledge the interrupt and schedule the higher level processing code. The higher level processing code is typically multi-threaded.
Should the interrupts be distributed across processors or should the interrupts be distributed in another fashion (e.g. round robin via hardware) then there are two problems at interrupt levelto resolve. One being interrupt level priority inconsistencies, and the second, and likely more important, is the interrupt code that has to post the scheduling event must now be written using thread-safe coding practices. Thread-safe coding practices often result in SpinLocks or other "dependent on other processor" types of delays. This in turn would cause some interrupts to be blocked (in interrupt service) while all interrupts (using thread-safe code)would run slower.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page