Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Ingo Molnar <mingo@xxxxxxx>
- Date: Thu, 6 Nov 2008 10:19:29 +0100
* Alexander van Heukelum <heukelum@xxxxxxxxxxx> wrote:
| > | Opteron (cycles): 1024 / 1157 / 3527
| > | Xeon E5345 (cycles): 1092 / 1085 / 6622
| > | Athlon XP (cycles): 1028 / 1166 / 5192
| >
| > Xeon is defenitely out of luck :-)
|
| it's still OK - i.e. no outrageous showstopper overhead anywhere in
| that instruction sequence. The total round-trip overhead is what will
| matter most.
|
| Ingo
|
Don't get me wrong please, I really like what Alexander have done!
But frankly six time slower is a bit scarying me.
the cost is 6 cycles instead of 1 cycles. In a codepath that takes
thousands of cycles and is often cache-limited.
Thanks again ;). Now it _is_ six times slower to do this tiny piece
of code... But please keep in mind all the activity that follows to
save the current data segment registers (the stack segment and code
segment are saved automatically), the general purpose registers and
to load most of the data segments with kernel-space values. And
looking at it now... do_IRQ is also not exactly trivial.
Also, I kept the information that is saved on the stack exactly the
same. If this is not a requirement, "push %cs" is what is left of
this expensive (6 cycle!) sequence. Even that could be unnecessary
if the stack layout can be changed... But I'ld like to consider that
separately.
we really want to keep the stack frame consistent between all the
context types. We can do things like return-to-userspace-from-irq or
schedule-from-irq-initiated-event, etc. - so crossing between these
context frames has to be standard and straightforward.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Alexander van Heukelum
- Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Ingo Molnar
- Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Alexander van Heukelum
- Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Ingo Molnar
- Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Alexander van Heukelum
- Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Cyrill Gorcunov
- Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Ingo Molnar
- Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Cyrill Gorcunov
- Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- From: Alexander van Heukelum
- [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- Prev by Date: [PATCH] Video/UVC: Port mainlined uvc video driver to NOMMU
- Next by Date: [PATCH] Input/AD7879: Fix/workaroud build error reported by Andrew Morton:
- Previous by thread: Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- Next by thread: Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
- Index(es):
Relevant Pages
|