<p>Hi Norman,</p><p>Here is the answer of some questions you asked me before:<br></p><p>

* It seems to introduce the notion of global IDs, which Genode tries   to avoid to counter problems like "ambient authority".<font color="#008000">There are no global IDs. The IDs are used to mark the task in mandatory access control, which is implemented in Monitor. * With my limited understanding of your changes, it looks like your   group implemented a classical ACL-policy mechanism right into the   heart of Genode. In my opinion, this approach contradicts with   the Genode's capability-based access-control model. I would   love to know the rationale behind this line of work and discuss   possible alternative solutions that are coherent with Genode's   design.<font color="#008000">The capability-based access-control model is similar to DAC model. We implemented a "Monitor" following MAC. * The code path is performance-critical, yet it performs slow string   compare operations and RPC calls.<font color="#008000">Maybe too many "connections" slow down the system. Would you like to give some advice on performance improvement on Qt5? Even the mouse cursor in the system cannot move fluently.  * It mixes different levels of abstractions. 'rpc_server.h' contains   the low-level message-dispatching mechanism whereas the notions of   objects, sessions, and connections are introduced on top of that.   By creating a "Monitor_connection" object within the low-level code   path, the low-level code becomes reliant on higher-level   abstractions that are built on top of the low-level code. Such   circular dependencies are not good.

</p><p><font color="#008000">It's really a matter to be solved.</font></p><br> Shuo Wang, <br>University of Chinese Academy of Sciences.<div> </div><div><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ original mail ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div> "norman.feske";<norman.feske@...1...>;</div><div> 2014-09-06 7:12 pm</div><div> "genode-main"<genode-main@lists.sourceforge.net>; </div><div> Re: Some questions about performance optimization related toGUIframework on Genode</div></div><div><br></div>Hello Shuo Wang,<br><br>> In Genode, it takes approximately 3 seconds for qt_launchpad to launch,<br>> and more than 1 seconds for other apps to launch. This is too slow, so<br>> my task is to reduce the launch time of qt_launchpad and apps. But I<br>> don't know what the reason of the low performance is. So I turn to you<br>> for some advice.<br><br>I cannot reproduce this observation. Please give the qt5 run script of<br>Genode 14.08 a try. When started on real hardware (not on Qemu!), Qt5<br>applications, including the qt_launchpad, open up instantly. I guess<br>that you performed your measurement either on Qemu, or using your<br>group's branch of Genode.<br><br>Speaking of this branch, I still could not get it running (see my last<br>email about the missing definition of L4_UTCB_USER_ID_OFFSET). However,<br>by quickly skimming over it, I have seen modifications that may impede<br>performance quite significantly. E.g., the following addition in the RPC<br>server code:<br><br><br>https://github.com/kloisiie/vsos/blob/master/base/include/base/rpc_server.h#L145-166<br><br>Not knowing the reasoning behind this code, I suspect that it goes<br>against the grain of Genode in several ways.<br><br>* It seems to introduce the notion of global IDs, which Genode tries<br>  to avoid to counter problems like "ambient authority".<br><br>* With my limited understanding of your changes, it looks like your<br>  group implemented a classical ACL-policy mechanism right into the<br>  heart of Genode. In my opinion, this approach contradicts with<br>  the Genode's capability-based access-control model. I would<br>  love to know the rationale behind this line of work and discuss<br>  possible alternative solutions that are coherent with Genode's<br>  design.<br><br>* The code path is performance-critical, yet it performs slow string<br>  compare operations and RPC calls.<br><br>* It mixes different levels of abstractions. 'rpc_server.h' contains<br>  the low-level message-dispatching mechanism whereas the notions of<br>  objects, sessions, and connections are introduced on top of that.<br>  By creating a "Monitor_connection" object within the low-level code<br>  path, the low-level code becomes reliant on higher-level<br>  abstractions that are built on top of the low-level code. Such<br>  circular dependencies are not good.<br><br>* It is specific to one particular kernel.<br><br>Given the huge amout of changes in your branch, there might be a good<br>chance that other performance-critical parts were changed for the worse,<br>too. To see whether the performance problems are actually on Genode's<br>account or stemming from the changes of your group, please check that<br>the problems can be reproduced on the unmodified version of Genode.<br><br>Best regards<br>Norman<br><br>-- <br>Dr.-Ing. Norman Feske<br>Genode Labs<br><br>http://www.genode-labs.com · http://genode.org<br><br>Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden<br>Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth<br><br>------------------------------------------------------------------------------<br>Slashdot TV.  <br>Video for Nerds.  Stuff that matters.<br>http://tv.slashdot.org/<br>_______________________________________________<br>genode-main mailing list<br>genode-main@lists.sourceforge.net<br>https://lists.sourceforge.net/lists/listinfo/genode-main<br></div>