getKernelWcetUs: where does the 10us return value come from?
Hi all, Quick questions regarding the return value of getKernelWcetUs(): 1. For ARM the value is assigned during build process taking config.cmake files, where KERNEL_WCET's are all 10us (except for tk1 it's 100us, typo?) For x86 the function returns 10 directly, and for risc-v, comment suggests it's copied from x86 hoping it's an overestimate. Where does this "10us" come from? Based on static estimate done previously on Armv6 (imx31)? AOS lecture mentioned a "378us" kernel WCET estimate and 99.5us observed WCET for Armv6. 2. Is this 10us WCET value the one used as padding in the Temporal Partitioning routine? ("worst-case flushing time"?) Regards, Jack
Hi Jack,
On 2 Dec 2021, at 23:23, Jack Chen via Devel
wrote: Quick questions regarding the return value of getKernelWcetUs():
1. For ARM the value is assigned during build process taking config.cmake files, where KERNEL_WCET's are all 10us (except for tk1 it's 100us, typo?) For x86 the function returns 10 directly, and for risc-v, comment suggests it's copied from x86 hoping it's an overestimate. Where does this "10us" come from? Based on static estimate done previously on Armv6 (imx31)? AOS lecture mentioned a "378us" kernel WCET estimate and 99.5us observed WCET for Armv6.
All of the current WCET config values are placeholders, because none of the current boards have undergone a real WCET analysis (the one that did have one was on Armv6). 100 for TK1 is not a typo AFAIR, but I don't quite remember the reason it is higher. The value is configurable, because it depends on how you set up the system. I.e. if you make certain operations impossible, which is entirely realistic for a hard-realtime system, you will get a much lower WCET than in a fully general, fully dynamic system.
2. Is this 10us WCET value the one used as padding in the Temporal Partitioning routine? ("worst-case flushing time"?)
Will have to leave that to someone who knows more about how the computation there works exactly. Cheers, Gerwin
Hi Gerwin, Thanks for the clarification :) Hope someone will answer my second question (Rephrasing my question: is checkBudget part of the implementation of temporal partitioning, with +WCET for padding?) Regards, Jack
On 3 Dec 2021, at 19:56, Jack Chen via Devel
Hope someone will answer my second question (Rephrasing my question: is checkBudget part of the implementation of temporal partitioning, with +WCET for padding?)
It’s to ensure there’s enough time left for handling the system call without violating budget constraints. Else you could help yourself to extra budget by a syscall just before budget expiry. Gernot
Does this have anything to do with Time Protection, covert channel prevention? Regards, Jack
No, that's a separate mechanism that is not merged yet. Cheers, Gerwin
On 9 Dec 2021, at 13:16, Jack Chen via Devel
wrote: Does this have anything to do with Time Protection, covert channel prevention?
Regards, Jack _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
participants (3)
-
Gernot Heiser
-
Gerwin Klein
-
Jack Chen