You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While developing tarable kernels/subkernels that can be ran as startup/idle kernels, I came across few problems. Due to increased DRTIO aux communications, it was much easier to interrupt an idle kernel during some operation and causing a panic - that's not too difficult to fix; same with large fragmented packets being cut off and possibly new data appending to it - that's also being taken care of currently.
With random interruptions though and processes going in the background, things do get more complex, to make things robust.
For example, a subkernel can keep running on a satellite and send a return value in an unfortunate moment, when an idle kernel is interrupted and a new one is loaded, putting its data where something else was expected. Basically, "late" replies may interfere with the next running kernel.
So it comes to idle kernel behavior in a way. A "normal" kernel would run until its completion, and within it all subkernels or DDMA would've been accounted for. Idle kernels by their looping and interruptible nature put more strict requirements on other subsystems, though.
I would like to know the real use cases, to analyze proper behavior.
Should idle kernels be ran in a loop, or just once after a 'normal' kernel?
Should idle kernels be interruptible?
How long do they usually take?
Would it be okay to have a non-trivial delay before running a 'normal' kernel after idle kernel has been stopped or interrupted?
@dhslichter I would love to hear some feedback from you.
The text was updated successfully, but these errors were encountered:
While developing tarable kernels/subkernels that can be ran as startup/idle kernels, I came across few problems. Due to increased DRTIO aux communications, it was much easier to interrupt an idle kernel during some operation and causing a panic - that's not too difficult to fix; same with large fragmented packets being cut off and possibly new data appending to it - that's also being taken care of currently.
With random interruptions though and processes going in the background, things do get more complex, to make things robust.
For example, a subkernel can keep running on a satellite and send a return value in an unfortunate moment, when an idle kernel is interrupted and a new one is loaded, putting its data where something else was expected. Basically, "late" replies may interfere with the next running kernel.
So it comes to idle kernel behavior in a way. A "normal" kernel would run until its completion, and within it all subkernels or DDMA would've been accounted for. Idle kernels by their looping and interruptible nature put more strict requirements on other subsystems, though.
I would like to know the real use cases, to analyze proper behavior.
@dhslichter I would love to hear some feedback from you.
The text was updated successfully, but these errors were encountered: