From: zyphr <infzyphr@gmail.com>
To: Zwane Mwaikambo <zwane@arm.linux.org.uk>,
Francesco Oppedisano <francesco.oppedisano@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: about interrupt latency
Date: Sun, 13 Mar 2005 18:13:24 +0100 [thread overview]
Message-ID: <3de2c80b05031309135460e07@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0503120952390.2166@montezuma.fsmlabs.com>
On Sat, 12 Mar 2005 10:01:43 -0700 (MST), Zwane Mwaikambo
<zwane@arm.linux.org.uk> wrote:
> On Wed, 9 Mar 2005, Francesco Oppedisano wrote:
>
> > On Tue, 8 Mar 2005 12:09:58 -0700 (MST), Zwane Mwaikambo
> > <zwane@arm.linux.org.uk> wrote:
> >
> > > At some cpu frequency point on i386 the main cause of your interrupt
> > > service latency will be in the interrupt controller and how long from irq
> > > assertion to the signal being recognised, resultant vector being
> > > dispatched to the processor and the necessary interrupt controller
> > > acknowledge steps required. This is also helped by the fact that the
> > > Linux/i386 interrupt vector stubs are very small and fast, so there isn't
> > > all that much code to execute to reach the ISR from the vector table. I'm
> > > not sure if you've tested this, but you may notice that timer interrupt
> > > via Local APIC will have lower dispatch latency than timer interrupt via
> > > i8259 only. But that's all at the lower end of the latency graph, you will
> > > most likely run into other sources on a busy system.
> > >
> > > Zwane
> > >
> > Very interesting zwane....i haven't tested the local APIC....do you
> > think this dispatch time can vary with the system I/O load (many
> > pending interrupts in the PIC)?
>
> The PIC/i386 setup cannot really pend interrupts so i would say no i don't
> think the dispatch time would be affected.
>
> > I think the interrupt latency is influenced even by the code inside
> > the kernel: if a lot of code is running with interrupts disabled then
> > the interrupt latency will grow. Am i right?
>
> Yes that's correct, in fact this will be your major/main cause of
> interrupt latency.
>
> > So probably we can state that the factors influencing the interrupt latency are:
> > 1)Dispatching time in the PIC
> > 2)Waiting time on the PIC (if there are pending interrupt of lower vector)
>
> With APIC/i386 this is more possible, if you're really interested you
> should try and calculate the dispatch time using the same system (must
> have an IOAPIC) and testing with the following combinations;
>
> PIC only (noapic, nolapic)
> PIC + LAPIC (noapic)
> IOAPIC + LAPIC
>
> You will probably find that the IOAPIC + LAPIC has the lowest dispatch
> time. Also worth noting that the LAPIC can queue upto 2 vectors (on P4),
> this allows for more interrupts to be ready for dispatch.
>
> > 3)fetching ISR from main memory
> > 4)wait time when CPU is running with disabled interrupt
> >
> > Do U agree?
>
> A bit more on (4)
>
> 4a) wait time when CPU is running firmware (e.g. SMI/SMM, VGA BIOSes etc)
>
> Otherwise, yes i agree, good luck with your research.
>
> Zwane
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I am just a user, not sure if it is related.
But with CONFIG_X86_UP_APIC and/or CONFIG_X86_UP_IOAPIC set my mouse
behaviour is totally different, when playing games everything feels
more "laggy".
And it gives me what gamers call "negative acceleration".
prev parent reply other threads:[~2005-03-14 13:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-08 18:39 about interrupt latency Francesco Oppedisano
2005-03-08 19:03 ` linux-os
2005-03-09 14:31 ` Francesco Oppedisano
2005-03-08 19:09 ` Zwane Mwaikambo
2005-03-09 14:43 ` Francesco Oppedisano
2005-03-12 17:01 ` Zwane Mwaikambo
2005-03-13 17:13 ` zyphr [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3de2c80b05031309135460e07@mail.gmail.com \
--to=infzyphr@gmail.com \
--cc=francesco.oppedisano@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zwane@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox