Answers of some questions about performance optimization relatedto GUIframework on Genode

[王硕]

Hello Norman,
Thank you for your advice. I will continue my experiment.


Have you compared the performance of an unmodified Genode system (e.g.,
qt5.run) with VSOS?
I have compared the performance of an unmodified Genode system (both 13.02 and 14.08) and VSOS both on qemu and real machine. The performance of them are similar which cannot satisfy our team leader/my advisor. He thought that it should be faster for apps on Genode (all operations should be finished at once), but both unmodified Genode and VSOS cannot satisfy him. He thought the problem may be related to inter-process communication between Init and ,or interaction between Qt and other parts of Genode, but I don't find out the problem in these aspects.

How are you testing VSOS (Qemu or real hardware)?‍
Yes, we have tested VSOS on real hardware for a long time in order to publish a distribution. It's really faster on real machine, but they still think it's too slow.

 Shuo Wang, 
University of Chinese Academy of Sciences.


 




------------------ 原始邮件 ------------------
发件人: "norman.feske";<norman.feske at ...1...>;
发送时间: 2014年9月10日(星期三) 晚上6:34
收件人: "genode-main"<genode-main at lists.sourceforge.net>; 

主题: Re: Answers of some questions about performance optimization relatedto GUIframework on Genode



Hi Shuo Wang,

unfortunately, I am extremely busy this and next week. So I could not
experiment with VSOS.

Thanks for considering my comments. However, you left a few of my
questions unanswered:

Have you compared the performance of an unmodified Genode system (e.g.,
qt5.run) with VSOS?

How are you testing VSOS (Qemu or real hardware)?

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

I think that implementing MAC by calling a policy module per RPC call at
user level is misguided. If a process possesses a capability, it has by
definition the right to access the resource referred-to by the
capability because the capability was delegated to the process
beforehand. Delegation implies the granting of the access right.

In a capability-based system, capabilities cannot be created out of thin
air. In order to use a capability, someone has to delegate it first. The
access-control (or better validity) check is done by the kernel (on
kernels that support capability-based security) each time a capability
is used.

Since a process owns no capabilities (except for the parent capability)
when started, each capability possessed by the process has already
passed the security policy by the originator of the capability when it
was delegated. So the access is authorized.

Instead of designing your system such that you need to check a MAC rule
database for critical capability invocations, just don't delegate
critical capabilities in the first place.

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

I suspect that you slightly misunderstand the idea behind
capability-based security. If used as intended (i.e., separating
different security concerns at the granularity of different
capabilities), no global "Monitor" with an all-encompassing policy
database is needed.

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

I'd like to assist if you have serious performance issues with the
unmodified Genode system. But please do not expect me to debug
performance issues that were introduced by your massive patch. To find
out whether the performance problems come from Genode or your patch,
please compare the performance of VSOS against the performance of an
unmodified Genode scenario.

As a general hint for investigating where the CPU time goes, you might
explore the Fiasco.OC kernel debugger. Using the "lp" command, you can
obtain a list of threads and their state. A stuttering mouse cursor may
be caused by a busy-looping thread (caused by a bug?). So first look for
the "ready" threads in the list. Furthermore, the kernel debugger is
able to print the amount CPU time used per thread (in the screen that
appears after selecting a thread). This may provide you with a first
indication of where the CPU time is consumed. Please refer to the manual
of the Fiasco kernel debugger [1] for more information. Unfortunately,
it is a bit out of date (written for the original L4/Fiasco kernel) but
most information is still applicable on Fiasco.OC.

[1] http://os.inf.tu-dresden.de/fiasco/doc/jdb.pdf

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

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
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/fe0452a2/attachment.html>