Hello Zhiyao,

 

Unfortunately, I also do not have a great explanation for you. At 64MHz (on the NRF52840DK), your benchmark takes 4846 ms.

 

I would like to point out some things. Your context switch diagram is underestimating the amount of context switches. The sequence you present is not correct because

If a syscall does not immediately error (which IPC is not doing in this case), then the kernel triggers a context switch (ContextSwitchReason::SyscallFired). To be more precise, the kernel's process loop is going to mark that a syscall has fired and ask the scheduler whether it should immediately handle the syscall. The default round robin scheduler will always choose to switch to the other process.

 

To revise your diagram:

On the "client" side:
- calls command() -> context switch to the kernel
- (NEW) kernel defers processing the command() -> kernel round robin scheduler context switches to server's main()
- (NEW) server app main loop immediately yields -> server context switches to kernel
- kernel processes the client's command -> kernel context switch to the client app
- client immediately runs yield_for -> context switch to kernel

I empirically verified that the `loop { yield(); }` runs 10,000 times in the server.

 

It is possible there is more overhead from the server calling `ipc_notify_client(pid);`, but I did not trace further in your timeline. I think the best method to get more info about this bug would be to do some debugging inside the kernel scheduler (`round_robin.rs`). Let me know if I got anything wrong, Professor Levy.

Samir

 

Hi Professor Levy,

Thank you so much for looking into the problem. Please let me know if there is anything I can help on my side.

Best regards,
Zhiyao
_______________________________________________
Devel mailing list -- devel@lists.tockos.org
To unsubscribe send an email to devel-leave@lists.tockos.org