Answers of some questions about performance optimization relatedto GUIframework on Genode

Wed Sep 10 13:27:02 CEST 2014

Hello. 

Let we make this conversation more substantive by adding metrics of performance. What does it mean «faster»? What you measure and how. How other people can estimate and compare performance? Could you please provide you metrics, information about testing environment and so. 

Thank you. 

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

-- 
Sartakov A. Vasily
sartakov at ...104...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.genode.org/pipermail/users/attachments/20140910/b4d6f3e9/attachment.sig>