lkml.org 
[lkml]   [2008]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
    Date

    On Tue, 4 Nov 2008 17:36:36 +0100, "Ingo Molnar" <mingo@elte.hu> said:
    >
    > * Alexander van Heukelum <heukelum@fastmail.fm> wrote:
    >
    > > I wonder how the time needed for reading the GDT segments balances
    > > against the time needed due to the extra redirection due to running
    > > the stubs. I'ld be interested if the difference can be measured with
    > > the current implementation. (I really need to highjack a machine to
    > > do some measurements; I hoped someone would do it before I got to it
    > > ;) )
    > >
    > > Even if some CPU's have some internal optimization for the case
    > > where the gate segment is the same as the current one, I wonder if
    > > it is really important... Interrupts that occur while the processor
    > > is running userspace already cause changing segments. They are more
    > > likely to be in cache, maybe.
    >
    > there are three main factors:
    >
    > - Same-value segment loads are optimized on most modern CPUs and can
    > give a few cycles (2-3) advantage. That might or might not apply to
    > the microcode that does IRQ entry processing. (A cache miss will
    > increase the cost much more but that is true in general as well)
    >
    > - A second effect is that the changed data structure layout: a more
    > compressed GDT entry (6 bytes) against a more spread out (~7 bytes,
    > not aligned) interrupt trampoline. Note that the first one is data
    > cache the second one is instruction cache - the two have different
    > sizes, different implementations and different hit/miss pressures.
    > Generally the instruction-cache is the more precious resource and we
    > optimize for that first, for data cache second.
    >
    > - A third effect is branch prediction: currently we are fanning
    > out all the vectors into ~240 branches just to recover a single
    > constant in essence. That is quite wasteful of instruction cache
    > resources, because from the logic side it's a data constant, not a
    > control flow difference. (we demultiplex that number into an
    > interrupt handler later on, but the CPU has no knowledge of that
    > relationship)
    >
    > ... all in one, the situation is complex enough on the CPU
    > architecture side for it to really necessiate a measurement in
    > practice, and that's why i have asked you to do them: the numbers need
    > to go hand in hand with the patch submission.
    >
    > My estimation is that if we do it right, your approach will behave
    > better on modern CPUs (which is what matters most for such things),
    > especially on real workloads where there's a considerable
    > instruction-cache pressure. But it should be measured in any case.

    Fully agreed. I will do some measurements in the near future, maybe
    next week. At least noone came up with an absolutely blocking problem
    with this approach ;).

    Greetings,
    Alexander

    > Ingo
    --
    Alexander van Heukelum
    heukelum@fastmail.fm

    --
    http://www.fastmail.fm - IMAP accessible web-mail



    \
     
     \ /
      Last update: 2008-11-04 17:49    [W:0.027 / U:91.020 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site