-----邮件原件-----
发件人: devel-request@sel4.systems [mailto:devel-request@sel4.systems]
发送时间: 2021年11月18日 5:56
收件人: devel@sel4.systems
主题: Devel Digest, Vol 125, Issue 2
Send Devel mailing list submissions to
devel@sel4.systems
To subscribe or unsubscribe via email, send a message with subject or body 'help' to
devel-request@sel4.systems
You can reach the person managing the list at
devel-owner@sel4.systems
When replying, please edit your Subject line so it is more specific than "Re: Contents of Devel digest..."
Today's Topics:
1. Re: some question about seL4 performance (Gerwin Klein)
2. Re: some question about seL4 performance (Gernot Heiser)
3. Re: some question about seL4 performance (Gerwin Klein)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Nov 2021 21:24:57 +0000
From: Gerwin Klein
On 18 Nov 2021, at 02:06, yadong.li
wrote: Hi: I learn the sel4 performance form https://sel4.systems/About/Performance/ I focus on the ARMv8 platform, from the website, the parameters are as follows: ISA Mode Core/SoC/Board Clock IRQ Invoke IPC call IPC reply "Armv8a 64 A57/Tx1/Jetson 1.9 GHz 863 (18) 396(15) 397(4)"
I want to know what is the length of IPC for the record provided on the web page , when test IPC call and reply? 0 or 10?
The page reports the 0-length numbers. The idea is that IPC should fit into registers, the 10 case is the one that make it spill into memory deliberately. That number is good to know for development, but should not be the main performance characteristic.
Cheers,
Gerwin
------------------------------
Message: 2
Date: Wed, 17 Nov 2021 21:36:39 +0000
From: Gernot Heiser
The page reports the 0-length numbers. The idea is that IPC should fit into registers, the 10 case is the one that make it spill into memory deliberately. That number is good to know for development, but should not be the main performance characteristic.
Note that whether data is transferred solely in registers or using a memory buffer does not make a big difference on contemporary hardware. However, our present implementation reverts to the slow path as soon as the message size overflows the physical message registers, which will make the PIC much slower.
This is something that could be fixed by widening the fastpath conditions without much complications. However, we haven’t yet come across an important use case where this matters, so there isn’t much motivation for investing time in it.
Gernot
------------------------------
Message: 3
Date: Wed, 17 Nov 2021 21:56:06 +0000
From: Gerwin Klein