[linux-audio-user] APIC is bad? What about hdparm?

[Chaz Worm]

Speaking of disagreements, I've seen two groups of thought on using 'hdparm'
to speed up a hard drive.  What is the final verdict?

chaz
----- Original Message -----
From: "Clemens Ladisch" <clemens at ladisch.de>
To: "A list for linux audio users" <linux-audio-user at music.columbia.edu>
Sent: Friday, July 16, 2004 12:06 PM
Subject: Re: [linux-audio-user] APIC is bad?


> Mark Knecht wrote:
> > No, you are exactly right. Clemens and I have some small technical
> > disagreements on this subject. We had a conversation that was
> > interesting but I think didn't yield any clear answers, at least in my
> > mind, so I freely admit I'm still confused on the subject.
> >
> > [...] As I remember the conversation the interrupt order was from
> > the highest interrupt number and going down from there, so if
> > Florin sees 25 interrupts, then #25 gets serviced first and that
> > would be where I'd want my sound card, if I could get it there.
>
> What I tried to explain was that the priority is not determined by the
> interrupt number but by the interrupt vector number.
>
> Well, let's see if my explanation isn't too muddy this time :-)
>
>
> The routing of interrupts from the hardware to the driver happens on
> three levels.
>
> First, there are the (PCI) interrupt lines, which are the input pins
> of the interrupt controller chip.  These are usually called
> PIRQA/B/C...  The only way to choose the interrupt line for the sound
> card is to put it into another PCI slot.  The interrupt line of
> integrated devices is usually fixed.
>
> The interrupt controller (PIC or I/O-APIC) has a number of hardware
> interrupts (PIC 16, I/O-APIC 24? or more).  Each interrupt line is
> mapped to one interrupt.  In PIC mode, the routing of interrupt line
> to interrupt number can be chosen by software (but is done by the BIOS
> in practice).  In I/O-APIC mode, the routing of interrupt lines to
> interrupts is fixed: each PCI interrupt line gets one of the
> interrupts above 15.
> These are the interrupt numbers shown in /proc/interrupts.
>
> The interrupts are mapped to interrupt vectors.  Intel CPUs have 256
> of them, but some are used for other purposes than hardware
> interrupts.  The interrupt vector numbers are chosen by the Linux
> kernel, and are fairly well hidden, but you can find them in the dmesg
> output if I/O-APIC is enabled.
>
>
> When the I/O-APIC is not enabled, interrupt priority is determined by
> the interrupt number (0 1 8 9 10 11 12 13 14 15 3 4 5 6 7).
>
> When the I/O-APIC is enabled, interrupt priority is determined by the
> interrupt vector number (lower vectors numbers have higher priority).
>
> (My patch to change vector numbers doesn't work with current kernels.)
>
>
> Regards,
> Clemens
>
>