Re: Why disabling/enabling interrupts is expensive operation?
From: Neil Horman (nhorman_at_lvl7.com)
Date: 08/05/03
- Next message: Kasper Dupont: "Re: Overlapping network requests"
- Previous message: Steve Adams: "Overlapping network requests"
- In reply to: Michael Rock: "Re: Why disabling/enabling interrupts is expensive operation?"
- Next in thread: John linville: "Re: Why disabling/enabling interrupts is expensive operation?"
- Reply: John linville: "Re: Why disabling/enabling interrupts is expensive operation?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 05 Aug 2003 13:34:43 -0400
Michael Rock wrote:
> On Tue, 5 Aug 2003, Neil Horman wrote:
>
> <snip>
>
>>Why do you think you need to flush the pipeline? Clearing and
>>re-enabling interrupts is a software event, none of the instructions
>>which affect the internal interrupt handling state (cli, sti, and their
>>cousins) affect the linearity of the instruction stream (they don't
>>branch to any location, etc.), and interrupt handling state changes
>
>
> Yes, they do. They enable/disable the nonlinearity any instrucion
> currently in the pipeline may raise. You may
> a) make the complete pipeline(s!) cli-aware so that cli can complete out
> of order, or you can
> b) flush the complete pipeline and do the thing syncronus.
>
No, they don't. The affected instruction need only be required to take
effect in the write-back stage of the pipeline, which by definition is
done serially, since instructions write back in order through the
reorder buffer. This means that the compiled order of an instruction
stream is enforced during the execution of a cli. If an event happens
prior to the execution of a cli which alters the flow of the instruction
stream (a branch, etc), the cli write-back will be suppressed,
preventing any processor state change from occuring due to that cli. If
an instruction stream flow change is processed in the execute stage of
the pipeline after a cli, the write-back of the cli instruction in the
re-order buffer will squash the results of the subsequent instruction.
The point here is, that while instructions may preform their associated
operations out of order (assuming no data or control dependencies), the
effect they may have on the internal processor state or the state of
memory, or other peripherals is accomplished strictly in order. This
means that you can get a partial speed up by doing multiple things at
once, while still ensuring that the functional order of your code is
preserved. Think about it: if it wasn't the case, how many other
problems might you encounter. consider the following example:
a=1
b=a*a
b=a+1
c=a+b
Assume here that the multiplication operator (*) takes, say 5 times as
long as the addition operator. Clearly b=a+1 will complete first, and
c=a+b can be assigned to the same functional unit, and so will result in
c=3, instead of c=2, as it should. How will the processor know to wait
for the second instruction to complete? The involved answer is rather
complex, involving various pipelining techniques (the Tomasulo
algorithm, etc), but the short version of the story is that instructions
are required to affect state changes to the hardware in order, and
instructions must wait for any immediately preceding data dependencies
to write their values back to the processor before they execute.
Its the same way with the cli instruction. It executes out of order,
but it doesn't change the processor state until the write back stage,
which is done in order. Previous instructions are by definition
complete, and any following instructions which may depend on the result
of the cli must wait for the cli to finish before they may execute.
> While a) may be fast in regard to the cli, it will surely have an impact
> in the performance of the complete system (extra logic stages). Solution
> b) will drain and refill the pipeline and have sti/cli/andsoon be slow as
> heck, but when you compare that with the use frequency of these insts, it
> pays off.
>
>
>>occur by modifying one of the processor registers. The register change
>>occurs during the writeback stage of the pipeline. Since writeback only
>>occurs after instructions have passed through the reorder buffer, you
>>can be guaranteed that any instruction which appears before a cli in the
>>compiled instruction stream has completed, and any instruction appearing
>>after the cli in the compiled instruction stream has yet to complete.
>
>
> Could be, but my bet is the extra logic would kill the speed improvement
> in the complete system.
>
No extra logic required. Its all part of the pipeline architecture
anyway, and it must be, for the reasons outlined above
>
>>Neil
>>
>>
>>
>
>
>
- Next message: Kasper Dupont: "Re: Overlapping network requests"
- Previous message: Steve Adams: "Overlapping network requests"
- In reply to: Michael Rock: "Re: Why disabling/enabling interrupts is expensive operation?"
- Next in thread: John linville: "Re: Why disabling/enabling interrupts is expensive operation?"
- Reply: John linville: "Re: Why disabling/enabling interrupts is expensive operation?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
