[PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes - Kernel

This is a discussion on [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes - Kernel ; On Tue, 04 Nov 2008 10:14:11 -0800, "H. Peter Anvin" said: > Alexander van Heukelum wrote: > > > > That's good to know. I assume this LOCKed bus cycle only occurs > > if the (hidden) segment information is ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 59

Thread: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

  1. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes


    On Tue, 04 Nov 2008 10:14:11 -0800, "H. Peter Anvin"
    said:
    > Alexander van Heukelum wrote:
    > >
    > > That's good to know. I assume this LOCKed bus cycle only occurs
    > > if the (hidden) segment information is not cached in some way?
    > > How many segments are typically cached? In particular, does it
    > > optimize switching between two segments?
    > >

    >
    > Yes, there is a segment descriptor cache (as opposed to the hidden but
    > architectural segment descriptor *registers*, which the Intel
    > documentation confusingly call a "cache".)
    >
    > It is used to optimize switching between a small number of segments, and
    > was crucial for decent performance on Win9x, which contained a bunch of
    > 16-bit code.


    Thanks for the info!

    This just means that if there are performance problems, the
    'specialized'
    handlers should be using the kernel segment or maybe a single common
    segment. It would still allow us to get rid of the trampolines. A stack
    trace should be enough to reconstruct which vector was originally called
    in that case. Only the common_interrupt-codepath needs the original
    vector as far as I can see.

    You just made testing on larger machines with a lot of external
    interrupts necessary :-/. (Assuming small machines do not show
    performance problems, that is.)

    Greetings,
    Alexander

    > -hpa

    --
    Alexander van Heukelum
    heukelum@fastmail.fm

    --
    http://www.fastmail.fm - I mean, what is it about a decent email service?

    --
    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/

  2. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Alexander van Heukelum wrote:
    >
    > Thanks for the info!
    >
    > This just means that if there are performance problems, the
    > 'specialized'
    > handlers should be using the kernel segment or maybe a single common
    > segment. It would still allow us to get rid of the trampolines. A stack
    > trace should be enough to reconstruct which vector was originally called
    > in that case. Only the common_interrupt-codepath needs the original
    > vector as far as I can see.
    >
    > You just made testing on larger machines with a lot of external
    > interrupts necessary :-/. (Assuming small machines do not show
    > performance problems, that is.)
    >


    Overall, it more than anything else show the x86 architectural
    braindamage of not having an interrupt vector number register available
    anywhere. However, I suspect using segment registers is liable to
    suffer from a "wall of jello" effect once you overflow the segment
    descriptor cache, which will typically be around 32 entries in size.

    Now, at least on my kernel, the existing IRQ stubs are rather weird:
    they are padded to 8 bytes and then misaligned onto a 4-byte boundary.
    Furthermore, at the cost of an extra jump, they can trivially be
    compressed down to 4 bytes apiece instead of 7-padded-to-8.

    -hpa
    --
    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/

  3. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Okay, looking at this some more, the current interrupt stubs are just
    plain braindead.

    We have a large number of push instructions which save a negative
    number, even when that means using the full 5-byte form; then we use:

    unsigned vector = ~regs->orig_ax;

    in do_IRQ. This is utterly moronic; if we use the short form push at
    all times, then we can set the upper bits (which distinguish us from a
    system call entry) at leisure (via a simple orl in common code), rather
    than in each stub, which to boot bloats it above the 8-byte mark.

    That way, each stub has the simple form:

    6A xx E9 yy yy yy yy 90

    Down to 8 bytes, including one byte of padding. Already better - we are
    down to 2K total, and each stub is aligned.

    Now, we can do better than that at the cost of an extra branch. The
    extra branch, however, is a direct unconditional branch and so is not
    subject to misprediction (good), although it may end up taking an extra
    icache miss (bad):

    we can group our vectors in 8 groups of 32 vectors each. Each contain a
    stub of the form:

    6A xx EB yy

    .... which jump to a common jump instruction at the end of each group.
    Thus, each group takes 32*4+5 bytes+3 bytes for alignment = 136 bytes,
    for a total of 1088 bytes.

    This has two disadvantages:
    - an extra jump.
    - we can no longer redirect a stub away from common code by
    changing the branch in that slot. We have to instead modify
    the IDT. This means "dedicated" interrupts don't get the
    vector number at all, which is probably fine -- to be honest,
    I'm not sure if they do at the moment either.

    Fixing the first of these I think is a no-brainer. That will cut the
    size of the existing stub pool by almost half. The second is more of a
    judgement call, and I'd like to see performance numbers for it. Either
    which way, I think it's worthwhile to consider this as an alternative to
    playing segmentation tricks, which I think could have really nasty
    side effects.

    -hpa

    --
    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/

  4. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Ingo Molnar wrote:
    > ( another advantage is that the 6 bytes GDT descriptor is more
    > compressed and hence uses up less L1/L2 cache footprint than the
    > larger (~7 byte) trampolines we have at the moment. )
    >


    Also its D cache rather than I cache, which is generally more
    plentiful. However, I think the cost of GDT cache misses on exception
    latency is something that we've largely overlooked, and this will make
    it a bigger factor (vs cache misses on the actual exception handler code
    itself, which should be reduced).

    J
    --
    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/

  5. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    H. Peter Anvin wrote:
    > - we can no longer redirect a stub away from common code by
    > changing the branch in that slot. We have to instead modify
    > the IDT. This means "dedicated" interrupts don't get the
    > vector number at all, which is probably fine -- to be honest,
    > I'm not sure if they do at the moment either.
    >


    They do, and the various patches to multiplex things like IPIs across
    multiple vectors rely on it.

    J
    --
    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/

  6. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Ingo Molnar wrote:
    > .. which we were able to avoid before. A couple of segment register
    > accesses, shifts, etc to calculate the vector - each of which can be
    > quite costly (especially the segment register access - this is a
    > relatively rare instruction pattern).
    >
    > I'm not unconvicable, but we need to be conservative here: could you
    > try to measure the full before/after cost of IRQ entry, to the cycle
    > level? I'm curious what the performance impact is.
    >
    > Also, this makes life probably a bit harder for Xen, which assumes
    > that the GDT of the guest OS is small-ish. (Jeremy Cc:-ed)
    >


    It doesn't increase the GDT to more than one page, so there's no issue
    there. The only reason the GDT uses a whole page is because of Xen's
    requirements anyway, so if we can make good use of the rest of the
    entries, so much the better.

    The other possible concern with Xen is whether Xen will properly load an
    arbitrary %cs on exception entry, or if it always loads KERNEL_CS; looks
    like it will load any %cs, so we should be fine there.

    Overall the patch looks good. Saving a segment register should be much
    faster than loading it, so I don't think the %cs read on entry should
    cost too much, but reloading %cs with KERNEL_CS might be a bit more of a
    cost (or does it run the whole exception with the new %cs?).

    J
    --
    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/

  7. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Jeremy Fitzhardinge wrote:
    > Ingo Molnar wrote:
    >> ( another advantage is that the 6 bytes GDT descriptor is more
    >> compressed and hence uses up less L1/L2 cache footprint than the
    >> larger (~7 byte) trampolines we have at the moment. )
    >>

    >
    > Also its D cache rather than I cache, which is generally more
    > plentiful. However, I think the cost of GDT cache misses on exception
    > latency is something that we've largely overlooked, and this will make
    > it a bigger factor (vs cache misses on the actual exception handler code
    > itself, which should be reduced).
    >


    Besides, a GDT entry is 8 bytes, not 6.

    -hpa
    --
    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/

  8. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    > Fixing the first of these I think is a no-brainer. That will cut the
    > size of the existing stub pool by almost half. The second is more of a
    > judgement call, and I'd like to see performance numbers for it. Either
    > which way, I think it's worthwhile to consider this as an alternative to
    > playing segmentation tricks, which I think could have really nasty
    > side effects.


    Or again just generate them on demand when the interrupt is set up.
    If you really have 240 interrupts sources you can afford the 5k likely,
    but for most there will be only a minimum number of stubs.

    Although frankly I suspect there are far easier ways to save 5k of memory.

    -Andi
    --
    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/

  9. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Andi Kleen wrote:
    >
    > Or again just generate them on demand when the interrupt is set up.
    > If you really have 240 interrupts sources you can afford the 5k likely,
    > but for most there will be only a minimum number of stubs.
    >
    > Although frankly I suspect there are far easier ways to save 5k of memory.
    >


    Generating them dynamically is probably pretty ugly too, though.

    Shrinking the whole table down to 2K by just regularizing the structure
    is trivial, though, and should almost certainly be a win. The more
    esoteric ideas are probably worse.

    -hpa
    --
    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/

  10. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    On Tue, Nov 04, 2008 at 12:26:13PM -0800, H. Peter Anvin wrote:
    > Andi Kleen wrote:
    > >
    > > Or again just generate them on demand when the interrupt is set up.
    > > If you really have 240 interrupts sources you can afford the 5k likely,
    > > but for most there will be only a minimum number of stubs.
    > >
    > > Although frankly I suspect there are far easier ways to save 5k of memory.
    > >

    >
    > Generating them dynamically is probably pretty ugly too, though.


    Why? The only slightly tricky thing is that they need to be in no NX space.
    Then it's just a few bytes patched in a template.

    > Shrinking the whole table down to 2K by just regularizing the structure
    > is trivial, though, and should almost certainly be a win. The more
    > esoteric ideas are probably worse.


    Just think how much memory you could safe elsewhere with the same
    effort.

    -Andi
    --
    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/

  11. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes


    * Alexander van Heukelum wrote:

    > On Tue, 4 Nov 2008 18:05:01 +0100, "Andi Kleen"
    > said:
    > > > not taking into account the cost of cs reading (which I
    > > > don't suspect to be that expensive apart from writting,

    > >
    > > GDT accesses have an implied LOCK prefix. Especially
    > > on some older CPUs that could be slow.
    > >
    > > I don't know if it's a problem or not but it would need
    > > some careful benchmarking on different systems to make sure interrupt
    > > latencies are not impacted.


    That's not a real issue on anything produced in this decade as we have
    had per CPU GDTs in Linux for about a decade as well.

    It's only an issue on ancient CPUs that export all their LOCKed cycles
    to the bus. Pentium and older or so. The PPro got it right already.

    What matters is what i said before: the actual raw cycle count before
    and after the patch, on the two main classes of CPUs, and the amount
    of icache we can save.

    > That's good to know. I assume this LOCKed bus cycle only occurs if
    > the (hidden) segment information is not cached in some way? How many
    > segments are typically cached? In particular, does it optimize
    > switching between two segments?
    >
    > > Another reason I would be also careful with this patch is that it
    > > will likely trigger slow paths in JITs like qemu/vmware/etc.

    >
    > Software can be fixed .


    Yes, and things like vmware were never a reason to hinder Linux.

    > > Also code segment switching is likely not something that current
    > > and future micro architectures will spend a lot of time
    > > optimizing.
    > >
    > > I'm not sure that risk is worth the small improvement in code
    > > size.

    >
    > I think it is worth exploring a bit more. I feel it should be a
    > neutral change worst-case performance-wise, but I really think the
    > new code is more readable/understandable.


    It's all measurable, so the vague "risk" mentioned above can be
    dispelled via hard numbers.

    > > An alternative BTW to having all the stubs in the executable would
    > > be to just dynamically generate them when the interrupt is set up.
    > > Then you would only have the stubs around for the interrupts which
    > > are actually used.

    >
    > I was trying to simplify things, not make it even less transparent
    > .


    yep, the complexity of dynamic stubs is the last thing we need here.

    And as hpa's comments point it out, compressing the rather stupid irq
    stubs might be a third option that looks promising as well.

    Ingo
    --
    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/

  12. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    On Tue, Nov 04, 2008 at 09:44:00PM +0100, Ingo Molnar wrote:
    >
    > * Alexander van Heukelum wrote:
    >
    > > On Tue, 4 Nov 2008 18:05:01 +0100, "Andi Kleen"
    > > said:
    > > > > not taking into account the cost of cs reading (which I
    > > > > don't suspect to be that expensive apart from writting,
    > > >
    > > > GDT accesses have an implied LOCK prefix. Especially
    > > > on some older CPUs that could be slow.
    > > >
    > > > I don't know if it's a problem or not but it would need
    > > > some careful benchmarking on different systems to make sure interrupt
    > > > latencies are not impacted.

    >
    > That's not a real issue on anything produced in this decade as we have
    > had per CPU GDTs in Linux for about a decade as well.
    >
    > It's only an issue on ancient CPUs that export all their LOCKed cycles
    > to the bus. Pentium and older or so. The PPro got it right already.


    ??? LOCK slowness is not because of the bus. And I know you know
    that Ingo, so I don't know why you wrote that bogosity above.

    > What matters is what i said before: the actual raw cycle count before
    > and after the patch, on the two main classes of CPUs, and the amount


    iirc there are at least between three and five classes of CPUs that
    matter (P6, K8, P4 and possibly Atom and C3). But I would only
    expect P4 to be a real problem.

    > > That's good to know. I assume this LOCKed bus cycle only occurs if
    > > the (hidden) segment information is not cached in some way? How many
    > > segments are typically cached? In particular, does it optimize
    > > switching between two segments?
    > >
    > > > Another reason I would be also careful with this patch is that it
    > > > will likely trigger slow paths in JITs like qemu/vmware/etc.

    > >
    > > Software can be fixed .

    >
    > Yes, and things like vmware were never a reason to hinder Linux.


    Hopefully the users agree with you on that.

    But anyways having to fix the JIT for saving 3-5k of memory would seem
    like a bad payoff in terms of effort:gain. Yes I know you personally
    wouldn't need to fix them, but wasting other engineer's time is nearly
    as bad as your own.

    > > > An alternative BTW to having all the stubs in the executable would
    > > > be to just dynamically generate them when the interrupt is set up.
    > > > Then you would only have the stubs around for the interrupts which
    > > > are actually used.

    > >
    > > I was trying to simplify things, not make it even less transparent
    > > .


    Doesn't make sense to me. The current code is not complex at all,
    just not particularly efficient. Yours might be better (at some
    risk), but simpler is probably not the right word to describe it.

    >
    > yep, the complexity of dynamic stubs is the last thing we need here.


    I don't think it's particularly complex. You just have a few bytes
    and you fill in the number and the target.

    -Andi
    --
    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/

  13. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes


    * Ingo Molnar wrote:

    > And as hpa's comments point it out, compressing the rather stupid
    > irq stubs might be a third option that looks promising as well.


    .... and we should try and see how far we can compress those stubs,
    before we do any segment register based tricks.

    Ingo
    --
    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/

  14. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Ingo Molnar wrote:
    > * Ingo Molnar wrote:
    >
    >> And as hpa's comments point it out, compressing the rather stupid
    >> irq stubs might be a third option that looks promising as well.

    >
    > ... and we should try and see how far we can compress those stubs,
    > before we do any segment register based tricks.
    >


    Using the techniques previously mentioned, for 224 vectors:

    1792 bytes ( 8 bytes/stub) - trivial.
    1568 bytes ( 7 bytes/stub) - same without alignment.
    952 bytes (~4 bytes/stub) - extra jump needed.

    For comparison, the IDT itself is 2048 bytes on x86-32 and 4096 bytes on
    x86-64.

    -hpa
    --
    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/

  15. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes


    * H. Peter Anvin wrote:

    > Ingo Molnar wrote:
    > > * Ingo Molnar wrote:
    > >
    > >> And as hpa's comments point it out, compressing the rather stupid
    > >> irq stubs might be a third option that looks promising as well.

    > >
    > > ... and we should try and see how far we can compress those stubs,
    > > before we do any segment register based tricks.
    > >

    >
    > Using the techniques previously mentioned, for 224 vectors:
    >
    > 1792 bytes ( 8 bytes/stub) - trivial.
    > 1568 bytes ( 7 bytes/stub) - same without alignment.
    > 952 bytes (~4 bytes/stub) - extra jump needed.
    >
    > For comparison, the IDT itself is 2048 bytes on x86-32 and 4096 bytes on
    > x86-64.


    sounds like a plan

    Ingo
    --
    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/

  16. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Andi Kleen wrote:
    > ??? LOCK slowness is not because of the bus. And I know you know
    > that Ingo, so I don't know why you wrote that bogosity above.
    >


    Why are the accesses locked? Is it because it does an update of the
    accessed bit in the descriptor? (We should be pre-setting them all anyway.)

    J
    --
    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/

  17. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Jeremy Fitzhardinge wrote:
    > Andi Kleen wrote:
    >> ??? LOCK slowness is not because of the bus. And I know you know that
    >> Ingo, so I don't know why you wrote that bogosity above.
    >>

    >
    > Why are the accesses locked? Is it because it does an update of the
    > accessed bit in the descriptor? (We should be pre-setting them all
    > anyway.)
    >


    It is, but the locked access is unconditional. Similar to any other
    read/modify/write transaction -- the write is required to release the lock.

    -hpa
    --
    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/

  18. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes


    * Andi Kleen wrote:

    > On Tue, Nov 04, 2008 at 09:44:00PM +0100, Ingo Molnar wrote:
    > >
    > > * Alexander van Heukelum wrote:
    > >
    > > > On Tue, 4 Nov 2008 18:05:01 +0100, "Andi Kleen"
    > > > said:
    > > > > > not taking into account the cost of cs reading (which I
    > > > > > don't suspect to be that expensive apart from writting,
    > > > >
    > > > > GDT accesses have an implied LOCK prefix. Especially
    > > > > on some older CPUs that could be slow.
    > > > >
    > > > > I don't know if it's a problem or not but it would need
    > > > > some careful benchmarking on different systems to make sure interrupt
    > > > > latencies are not impacted.

    > >
    > > That's not a real issue on anything produced in this decade as we have
    > > had per CPU GDTs in Linux for about a decade as well.
    > >
    > > It's only an issue on ancient CPUs that export all their LOCKed
    > > cycles to the bus. Pentium and older or so. The PPro got it right
    > > already.

    >
    > ??? LOCK slowness is not because of the bus. And I know you know
    > that Ingo, so I don't know why you wrote that bogosity above.


    ... of course the historic LOCK slowness was all due to the system bus:
    very old CPUs exported a LOCK signal to the system bus for every
    LOCK-prefix access (implicit and explicit) and that made it _really_
    expensive. (hundreds of cycles)

    .... on reasonably modern CPUs the LOCK-ed access has been abstracted
    away to within the CPU, and the cost of LOCK-ed access is rather low
    (think 10-20 cycles - of course only if there's no cache miss cost)
    (That's obviously the case with the GDT, with is both per CPU and well
    cached.)

    on _really_ modern CPUs LOCK can be as cheap as just a few cycles - so
    low that we can stop bothering about it in the future. There's no
    fundamental physical reason why the LOCK prefix (implicit or explicit)
    should be expensive.

    the real reason why Alexander's patch needs to be measured is not the
    LOCK cycle of GDT accesses but what i pointed out in my first mail:
    the segmentation trick it plays. And that's why shrinking the stubs is
    probably a better idea which should be tried first.

    .... anyway, the unacceptable tone of your reply shows that you still
    have not changed a bit in your old habit of attacking and bullying
    people on lkml. All the other Intel engineers i'm working with as a
    maintainer show a very professional approach and are very easy to work
    with. You need to stop your attacks, and until you change this
    negative way of working with people i'll continue to ignore you.

    Ingo
    --
    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/

  19. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    [Ingo Molnar - Tue, Nov 04, 2008 at 10:52:45PM +0100]
    |
    | * H. Peter Anvin wrote:
    |
    | > Ingo Molnar wrote:
    | > > * Ingo Molnar wrote:
    | > >
    | > >> And as hpa's comments point it out, compressing the rather stupid
    | > >> irq stubs might be a third option that looks promising as well.
    | > >
    | > > ... and we should try and see how far we can compress those stubs,
    | > > before we do any segment register based tricks.
    | > >
    | >
    | > Using the techniques previously mentioned, for 224 vectors:
    | >
    | > 1792 bytes ( 8 bytes/stub) - trivial.
    | > 1568 bytes ( 7 bytes/stub) - same without alignment.
    | > 952 bytes (~4 bytes/stub) - extra jump needed.
    | >
    | > For comparison, the IDT itself is 2048 bytes on x86-32 and 4096 bytes on
    | > x86-64.
    |
    | sounds like a plan
    |
    | Ingo
    |

    Ingo, what the conclusion is? As I understand from the thread --

    1) Implement Peter's proposed cleanup/compress.
    2) Test Alexander's patche.

    Did I miss something?

    - Cyrill -
    --
    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/

  20. Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

    Cyrill Gorcunov wrote:
    >
    > Ingo, what the conclusion is? As I understand from the thread --
    >
    > 1) Implement Peter's proposed cleanup/compress.
    > 2) Test Alexander's patche.
    >
    > Did I miss something?
    >


    Nope, that's pretty much it.

    However, there are good reason to believe that using this kind of
    segment selector tricks is probably a bad idea in the long term,
    especially since CPU vendors have strong incentives to reduce the size
    of the segment descriptor cache now when none of the mainstream OSes
    rely on more than a small handful of segments.

    I was planning to look at doing the obvious stub shrink today.

    -hpa
    --
    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/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast