[Embench] Interrupts ( Embench Digest, Vol 16, Issue 2)

Roger Shepherd roger.shepherd at chipless.eu
Mon Nov 16 12:36:08 CET 2020


I think I may be missing a little context for this discussion. Has the rationale or objectives for this benchmark been written? From my experience, doing so exposes a lot of choices that have to be made, and how those choices get made depends on what you are trying to do. I don’t have a good way to structure the issues so the rest of this mail may seem a little unstructured - sorry - and it certainly isn’t comprehensive. Its purpose is to encourage the creation of a rationale.


1. Software environment

What is the software environment that we are concerned with? Bare machine? Language system? Small/real-time kernel or operating system? What environment does “an interrupt” execute in? What can an interrupt do to the rest of the software system?

For example, if the processor is running a "language system” and the software run in an interrupt is written in that language, then the latency of the interrupt ought to include the cost of setting up the environment that the interrupt software runs in. And the “overhead” cost of taking the interrupt should include that set-up cost and the corresponding break-down cost on exit.

Another example, some processors have mechanisms which may help with interrupt latency and overhead, but it turns out that these mechanisms can’t (or aren’t) used by an operating system. (I recall this is why the original MIPS architecture did not have vectored interrupts - Unix funnelled all interrupts through the same hole).

Finally, when running a full-blown operating system, the interrupt latency can be determined by how long various locks are held within the operating system - and these can be long.


2. Hardware environment

What’s the structure of the computer system? The memory structure matters. Even without caches the memory system is often not uniform - on-chip RAM, ROM, FLASH, external SRAM, DRAM. E.G. 1. You may get faster response if your interrupt code lives in SRAM rather than FLASH - does your software system let you exploit this? E.G. 2. DRAM refresh cycles can increase latency.


3. Nested interrupts

Is there an interest in measuring the behaviour of multiple, prioritised interrupts?


4. Latency

I’m interested in how long it takes from an EVENT occurring to the processor taking an ACTION.

What EVENTS? - internal (e.g. timers), software generated, external?

What ACTIONS? Changing some internal state? Causing something to happen externally?


5. Cost

How much time - above that needed for the action of the interrupt - does taking the interrupt cost? This would include environment set-up and break-down for the interrupt code, but might also include the cost of re-executing a long-running instruction that was abandoned when the interrupt was taken.

There’s also the impact that one interrupt might have on another. Even without the complexity of a prioritised multiple interrupt system, there is the question of the latency (etc) of a second interrupt, for example, assuming interrupts don’t do anything except set-up, break-down and return.


6. Jitter

What is the distribution of the latency?


7. How are measurements to be made?

And does the act of measuring affect the behaviour?


I only have three strong opinions about this. The first is that we do need to set out our objectives. The second is that we have to keep things simple. And the third is that we ought to consider the software context.


Best

Roger



> On 15 Nov 2020, at 07:04, Ronen Haen <Ronen.Haen at wdc.com> wrote:
> 
> Hi,
> 
> 1. Jon, M_PSP_PUSH and M_PSP_POP are context save/restore; this initial proposal only includes measurements w/o FW overhead. Next step would be adding FW overhead (called into a c-function interrupt handler)
> 2. Jeremy, I can present this proposal at Monday's meeting.
> 
> Thanks,
> Ronen
> 
> -----Original Message-----
> From: Embench <embench-bounces at lists.librecores.org> On Behalf Of embench-request at lists.librecores.org
> Sent: Friday, 13 November 2020 13:00
> To: embench at lists.librecores.org
> Subject: Embench Digest, Vol 16, Issue 2
> 
> CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.
> 
> 
> Send Embench mailing list submissions to
>        embench at lists.librecores.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.librecores.org/listinfo/embench
> or, via email, send a message with subject or body 'help' to
>        embench-request at lists.librecores.org
> 
> You can reach the person managing the list at
>        embench-owner at lists.librecores.org
> 
> When replying, please edit your Subject line so it is more specific than "Re: Contents of Embench digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: PR - RV interrupt latency benchmark proposal (Jon Taylor)
>   2. Re: PR - RV interrupt latency benchmark proposal (Jeremy Bennett)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 13 Nov 2020 08:00:48 +0000
> From: Jon Taylor <Jon.Taylor at arm.com>
> To: "embench at lists.librecores.org" <embench at lists.librecores.org>
> Cc: nd <nd at arm.com>
> Subject: Re: [Embench] PR - RV interrupt latency benchmark proposal
> Message-ID:
>        <AM5PR0801MB16511F6DCDEF4918FE04543393E60 at AM5PR0801MB1651.eurprd08.prod.outlook.com>
> 
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Ronen,
> 
> Thanks for sharing this. Please can you clarify the macros M_PSP_PUSH and M_PSP_POP? I can’t see them in the embench tree anywhere. I assume they’re some sort of context save/restore.
> 
> What I would observe is that by stopping the timer as soon as you enter the ASM interrupt handler, there’s no timing of a C prologue that you’d need if the handler was a c-function (or called into a c-function). Would it be more representative to stop the timer once the code has reached the specific C handler function?
> 
> Regards,
> 
> Jon
> 
> From: Embench <embench-bounces at lists.librecores.org> On Behalf Of Ronen Haen
> Sent: 10 November 2020 07:57
> To: embench at lists.librecores.org
> Subject: [Embench] PR - RV interrupt latency benchmark proposal
> 
> Hi All,
> 
> I’ve created a PR https://github.com/embench/embench-context-latency/pull/1
> Your comments would be much appreciated.
> 
> Thanks,
> Ronen
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.librecores.org/pipermail/embench/attachments/20201113/4f7474f3/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 13 Nov 2020 08:25:29 +0000
> From: Jeremy Bennett <jeremy.bennett at embecosm.com>
> To: embench at lists.librecores.org
> Subject: Re: [Embench] PR - RV interrupt latency benchmark proposal
> Message-ID: <a56992e2-3f6c-cedb-8398-4f17f7a26920 at embecosm.com>
> Content-Type: text/plain; charset=utf-8
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/11/2020 07:57, Ronen Haen wrote:
>> Hi All,
>> 
>> I’ve created a PR
>> https://github.com/embench/embench-context-latency/pull/1
>> 
>> Your comments would be much appreciated.
> 
> Hi Ronen,
> 
> Thanks for your work on this. Would you be willing to present it at Monday's meeting?
> 
> Best wishes,
> 
> 
> Jeremy
> 
>> 
>> 
>> 
>> Thanks,
>> 
>> Ronen
>> 
>> 
>> 
>> 
> 
> 
> - --
> Cell: +44 (7970) 676050
> SkypeID: jeremybennett
> Twitter: @jeremypbennett
> Email: jeremy.bennett at embecosm.com
> Web: www.embecosm.com
> PGP key: 1024D/BEF58172FB4754E1 2009-03-20 -----BEGIN PGP SIGNATURE-----
> 
> iF0EARECAB0WIQRASGDWqmhRZUfAaPW+9YFy+0dU4QUCX65C9wAKCRC+9YFy+0dU
> 4bDOAKCTp+wLivNj43/TFU2Bu69RcvQy+gCeISukpRMbSwSRLqJWpFSxt96B324=
> =3XSm
> -----END PGP SIGNATURE-----
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> Embench mailing list
> Embench at lists.librecores.org
> https://lists.librecores.org/listinfo/embench
> 
> 
> ------------------------------
> 
> End of Embench Digest, Vol 16, Issue 2
> **************************************
> --
> Embench mailing list
> Embench at lists.librecores.org
> https://lists.librecores.org/listinfo/embench

--
Roger Shepherd
roger.shepherd at chipless.eu




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/embench/attachments/20201116/61f778ec/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.librecores.org/pipermail/embench/attachments/20201116/61f778ec/attachment.sig>


More information about the Embench mailing list