Green task stacks

[Igor]

Hello!

Genode Thread class already have infrastructure for implementing the green tasks: alloc_secondary_stack() which used i.e. in dde_linux to emulate the Linux kernel behavior. These secondary stacks have fixed maximal size and live one below another, so they can overlap each other. It is possible to create different Dataspace lists for each green stack and then switch them. Right now Genode hasn't the method for switching several DSs at once, so each DS in that list should be switched individually which would be too expensive.

The question is: even having that method, can we still consider our tasks "green"? Or such complexity is no better than the ordinal thread complexity?

Thanks!

[Stefan Kalkowski]

Hello Igor,

Post by Igor
Hello!
Genode Thread class already have infrastructure for implementing the green tasks: alloc_secondary_stack() which used i.e. in dde_linux to emulate the Linux kernel behavior.

Yes, that is correct.

Post by Igor
These secondary stacks have fixed maximal size and live one below another, so they can overlap each other.

That is a false assumption. You can define the stack size (second
argument of 'alloc_secondary_stack'), and there is always room in
between the different stacks so that a stack overflow should lead to a
page-fault. Where does your assumption come from?

Post by Igor
It is possible to create different Dataspace lists for each green stack and then switch them. Right now Genode hasn't the method for switching several DSs at once, so each DS in that list should be switched individually which would be too expensive.

I do not know what you mean with dataspace switching. With regard to
thread stacks, it is the stack pointer (a designated register), which is
changed, nothing is changed with regard to the address space layout. In
general, all threads within one component share the same view with
regard to the memory layout. Therefore, I'm not sure what you mean with
"dataspace switching"?

Best regards
Stefan

Post by Igor
The question is: even having that method, can we still consider our tasks "green"? Or such complexity is no better than the ordinal thread complexity?
Thanks!
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Igor]

Hello Stefan!

Post by Stefan Kalkowski
Hello Igor,

 Hello!
 Genode Thread class already have infrastructure for implementing the green tasks: alloc_secondary_stack() which used i.e. in dde_linux to emulate the Linux kernel behavior.

Yes, that is correct.

 These secondary stacks have fixed maximal size and live one below another, so they can overlap each other.

That is a false assumption. You can define the stack size (second
argument of 'alloc_secondary_stack'), and there is always room in
between the different stacks so that a stack overflow should lead to a
page-fault. Where does your assumption come from?

 It is possible to create different Dataspace lists for each green stack and then switch them. Right now Genode hasn't the method for switching several DSs at once, so each DS in that list should be switched individually which would be too expensive.

I do not know what you mean with dataspace switching. With regard to
thread stacks, it is the stack pointer (a designated register), which is
changed, nothing is changed with regard to the address space layout. In
general, all threads within one component share the same view with
regard to the memory layout. Therefore, I'm not sure what you mean with
"dataspace switching"?

Indeed there are guard pages between secondary stacks. But what happens when "top" stack reaches the guard page of "bottom" stack? I mean, what should I do in the page fault handler? As far as I understand, I should somehow preserve the first page (and eventually another ones) of "bottom" stack. In general, it requires stack pages switching, right?

Thank you for answer. You know, Genode is perfect environment for languages like Go and Erlang. So for now I mentally try to resolve possible porting problems. Second problem is interaction with already existed Genode components. I think that Ipc_istream and Ipc_ostream are the right places. Not sure about signaling though.

Post by Stefan Kalkowski
Best regards
Stefan

 The question is: even having that method, can we still consider our tasks "green"? Or such complexity is no better than the ordinal thread complexity?
 Thanks!
 ------------------------------------------------------------------------------
 Site24x7 APM Insight: Get Deep Visibility into Application Performance
 APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
 Monitor end-to-end web transactions and take corrective actions now
 Troubleshoot faster and improve end-user experience. Signup Now!
 http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
 _______________________________________________
 genode-main mailing list
 https://lists.sourceforge.net/lists/listinfo/genode-main

--
Stefan Kalkowski
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main