Answers of some questions about performance optimization related to GUIframework on Genode

[王硕]

Hi Norman,

Here is the answer of some questions you asked me before:


 * It seems to introduce the notion of global IDs, which Genode tries
  to avoid to counter problems like "ambient authority".

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.

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.

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. 

It's really a matter to be solved.

 Shuo Wang, 
University of Chinese Academy of Sciences. 




------------------ original mail ------------------
 "norman.feske";<norman.feske at ...1...>;
 2014-09-06 7:12 pm
 "genode-main"<genode-main at lists.sourceforge.net>; 
 Re: Some questions about performance optimization related toGUIframework on Genode



Hello Shuo Wang,

> In Genode, it takes approximately 3 seconds for qt_launchpad to launch,
> and more than 1 seconds for other apps to launch. This is too slow, so
> my task is to reduce the launch time of qt_launchpad and apps. But I
> don't know what the reason of the low performance is. So I turn to you
> for some advice.

I cannot reproduce this observation. Please give the qt5 run script of
Genode 14.08 a try. When started on real hardware (not on Qemu!), Qt5
applications, including the qt_launchpad, open up instantly. I guess
that you performed your measurement either on Qemu, or using your
group's branch of Genode.

Speaking of this branch, I still could not get it running (see my last
email about the missing definition of L4_UTCB_USER_ID_OFFSET). However,
by quickly skimming over it, I have seen modifications that may impede
performance quite significantly. E.g., the following addition in the RPC
server code:


https://github.com/kloisiie/vsos/blob/master/base/include/base/rpc_server.h#L145-166

Not knowing the reasoning behind this code, I suspect that it goes
against the grain of Genode in several ways.

* It seems to introduce the notion of global IDs, which Genode tries
  to avoid to counter problems like "ambient authority".

* 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.

* The code path is performance-critical, yet it performs slow string
  compare operations and RPC calls.

* 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.

* It is specific to one particular kernel.

Given the huge amout of changes in your branch, there might be a good
chance that other performance-critical parts were changed for the worse,
too. To see whether the performance problems are actually on Genode's
account or stemming from the changes of your group, please check that
the problems can be reproduced on the unmodified version of Genode.

Best regards
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
genode-main mailing list
genode-main at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20140910/14fafd82/attachment.html>