Hello Norman,
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 use Rtc (\os\src\drivers\rtc\x86) to record the launch time of qt_launchpad and apps as listed below:
in main.cpp of qt_launchpad:
int main(int argc, char *argv[]) { /*Use Rtc to record the time*/ ... ... launchpad->show(); /*Use Rtc to record the time again*/ ... ... }
in launch_entry.cpp of qt_launchpad:
void Launch_entry::on_launchButton_clicked() {
/*Use Rtc to record the time*/ _launchpad->start_child(_filename, ...);
/*Use Rtc to record the time again*/ }
Shuo Wang, University of Chinese Academy of Sciences.
--------Original mail-------- Sender: norman.feske <norman.feske@...1...> (by genode-main-bounces@lists.sourceforge.net ) Time: 2014-09-01 (Mon) 12:00 (UTC+02:00) Receiver: genode-main genode-main@lists.sourceforge.net Hello Shuo Wang,
The Git branch of our genode is listed below: https://github.com/kloisiie/vsos
thanks for making your modifications publicly available. But I am wondering:
Why haven't you just forked the Genode repository? See
https://github.com/genodelabs/genode
By having imported a snapshot of the source code to a new repository, you removed all the history and cannot easily follow the mainline development. For me, this makes it almost impossible to spot your modifications. Why haven't you just applied your changes as a topic branch on top of the regular Genode repository?
Moreover, why have you removed the LICENSE file from top-level directory? The license is important information and should always be prominently visible.
I would also recommend to keep the original README file or, at least, provide a link to the original Genode repository.
- Have you tried to run your GUI application on base-linux? If yes,
have you compared its performance to the same application compiled for native Linux w/o Genode? Our apps is Fiasco.OC-specific, so I don't know how to run these apps on base-linux.
- On base-linux, you could use normal Linux profiling tools such as
oprofile to find out where the CPU time goes. Please recommend some similar tools on base-foc.
There is no such tool for base-foc. For this reason, I recommended to run the application on base-linux in the first place.
Even if you application depends on Fiasco.OC, you might still use any of the other (portable) example applications to investigate an eventual performance problem of Qt. First check if the behavior that you noticed can be reproduced with one of those example applications. If that is the case, run the same application on Linux and use oprofile to investigate.
- Can you make a Git branch with your application publicly available
https://github.com/kloisiie/vsos%E2%80%8D To run the vsos, use $ ./create_builddir fox_x86_32 build_dir=~/<build-directory> to create a build directory, and then execute $ make run/verify in build directory.
Unfortunately, I am not able to compile it. I get an error as follows:
/open/incoming/vsos/base/include/base/rpc_server.h:152:41: error: ‘l4_utcb_id’ is not a member of ‘Fiasco’
The type 'l4_utcb_id' does not exist in the 'base-foc/contrib' source tree. It seems like you changed the kernel but invoking 'make prepare' within 'base-foc' fetches the original kernel.
Best regards Norman
Hi,
just a side advice: do not use RTC as i also tried to measure some actions.
I tried the following rtc1 = rtc.get_current_time(); rtc2 = rtc.get_current_time(); and always got a difference of 1 second. (in a loop) – and that was only with calling rtc.
So i looked at RTC ( https://github.com/genodelabs/genode/blob/master/repos/os/src/drivers/rtc/x8... ) and found: “return mktime(day, mon, year, hour, min, sec) * 1000000ULL;” so it only has a precision of one second and only gives you a value that looks like it could have a higher precision.
Take alook at RDTSC in https://github.com/genodelabs/genode/tree/master/repos/os/include/x86_64/tra... This will inline the code so you do not have costly RPC calls.
RDTSC will give you huge numbers, the prozessor counters. If your prozessor is running at for example 2.4 Ghz you will see values for one second around 2.400.000.000 (can differ a bit as machines are not running exactly at x Mhz). With the machine i tested it is still not completly accurate, but has a standard deviation less then 50 microseconds.
Best regards Wolfgang
From: 王硕 Sent: Friday, September 5, 2014 10:24 PM To: genode-main Subject: Re: Some questions about performance optimization related toGUIframework on Genode
Hello Norman,
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 use Rtc (\os\src\drivers\rtc\x86) to record the launch time of qt_launchpad and apps as listed below:
in main.cpp of qt_launchpad:
int main(int argc, char *argv[]) { /*Use Rtc to record the time*/ ... ... launchpad->show(); /*Use Rtc to record the time again*/ ... ... }
in launch_entry.cpp of qt_launchpad:
void Launch_entry::on_launchButton_clicked() {
/*Use Rtc to record the time*/ _launchpad->start_child(_filename, ...);
/*Use Rtc to record the time again*/ }
Shuo Wang, University of Chinese Academy of Sciences.
--------Original mail-------- Sender: norman.feske <norman.feske@...1...> (by genode-main-bounces@lists.sourceforge.net ) Time: 2014-09-01 (Mon) 12:00 (UTC+02:00) Receiver: genode-main genode-main@lists.sourceforge.net Hello Shuo Wang,
The Git branch of our genode is listed below: https://github.com/kloisiie/vsos
thanks for making your modifications publicly available. But I am wondering:
Why haven't you just forked the Genode repository? See
https://github.com/genodelabs/genode
By having imported a snapshot of the source code to a new repository, you removed all the history and cannot easily follow the mainline development. For me, this makes it almost impossible to spot your modifications. Why haven't you just applied your changes as a topic branch on top of the regular Genode repository?
Moreover, why have you removed the LICENSE file from top-level directory? The license is important information and should always be prominently visible.
I would also recommend to keep the original README file or, at least, provide a link to the original Genode repository.
- Have you tried to run your GUI application on base-linux? If yes,
have you compared its performance to the same application compiled for native Linux w/o Genode? Our apps is Fiasco.OC-specific, so I don't know how to run these apps on base-linux.
- On base-linux, you could use normal Linux profiling tools such as
oprofile to find out where the CPU time goes. Please recommend some similar tools on base-foc.
There is no such tool for base-foc. For this reason, I recommended to run the application on base-linux in the first place.
Even if you application depends on Fiasco.OC, you might still use any of the other (portable) example applications to investigate an eventual performance problem of Qt. First check if the behavior that you noticed can be reproduced with one of those example applications. If that is the case, run the same application on Linux and use oprofile to investigate.
- Can you make a Git branch with your application publicly available
https://github.com/kloisiie/vsos%E2%80%8D To run the vsos, use $ ./create_builddir fox_x86_32 build_dir=~/<build-directory> to create a build directory, and then execute $ make run/verify in build directory.
Unfortunately, I am not able to compile it. I get an error as follows:
/open/incoming/vsos/base/include/base/rpc_server.h:152:41: error: ‘l4_utcb_id’ is not a member of ‘Fiasco’
The type 'l4_utcb_id' does not exist in the 'base-foc/contrib' source tree. It seems like you changed the kernel but invoking 'make prepare' within 'base-foc' fetches the original kernel.
Best regards Norman
Dear w_schmidt,
Thank you for your advice on measurement. My advisor hope me to solve the performance bottleneck on IPC, so it will reduce the side effect of measurement.
Shuo Wang, University of Chinese Academy of Sciences.
------------------ Original Mail ------------------ "w_schmidt";<w_schmidt@...181...>; "genode-main"genode-main@lists.sourceforge.net; Re: Some questions about performance optimization relatedtoGUIframework on Genode
Hi,
just a side advice: do not use RTC as i also tried to measure some actions.
I tried the following rtc1 = rtc.get_current_time(); rtc2 = rtc.get_current_time(); and always got a difference of 1 second. (in a loop) – and that was only with calling rtc.
So i looked at RTC ( https://github.com/genodelabs/genode/blob/master/repos/os/src/drivers/rtc/x8... ) and found: “return mktime(day, mon, year, hour, min, sec) * 1000000ULL;” so it only has a precision of one second and only gives you a value that looks like it could have a higher precision.
Take alook at RDTSC in https://github.com/genodelabs/genode/tree/master/repos/os/include/x86_64/tra... This will inline the code so you do not have costly RPC calls.
RDTSC will give you huge numbers, the prozessor counters. If your prozessor is running at for example 2.4 Ghz you will see values for one second around 2.400.000.000 (can differ a bit as machines are not running exactly at x Mhz). With the machine i tested it is still not completly accurate, but has a standard deviation less then 50 microseconds.
Best regards Wolfgang
From: 王硕 Sent: Friday, September 5, 2014 10:24 PM To: genode-main Subject: Re: Some questions about performance optimization related toGUIframework on Genode
Hello Norman,
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 use Rtc (\os\src\drivers\rtc\x86) to record the launch time of qt_launchpad and apps as listed below:
in main.cpp of qt_launchpad:
int main(int argc, char *argv[]) { /*Use Rtc to record the time*/ ... ... launchpad->show(); /*Use Rtc to record the time again*/ ... ... }
in launch_entry.cpp of qt_launchpad:
void Launch_entry::on_launchButton_clicked() {
/*Use Rtc to record the time*/ _launchpad->start_child(_filename, ...);
/*Use Rtc to record the time again*/ }
Shuo Wang, University of Chinese Academy of Sciences.
--------Original mail-------- Sender: norman.feske <norman.feske@...1...> (by genode-main-bounces@lists.sourceforge.net ) Time: 2014-09-01 (Mon) 12:00 (UTC+02:00) Receiver: genode-main genode-main@lists.sourceforge.net Hello Shuo Wang,
The Git branch of our genode is listed below: https://github.com/kloisiie/vsos
thanks for making your modifications publicly available. But I am wondering:
Why haven't you just forked the Genode repository? See
https://github.com/genodelabs/genode
By having imported a snapshot of the source code to a new repository, you removed all the history and cannot easily follow the mainline development. For me, this makes it almost impossible to spot your modifications. Why haven't you just applied your changes as a topic branch on top of the regular Genode repository?
Moreover, why have you removed the LICENSE file from top-level directory? The license is important information and should always be prominently visible.
I would also recommend to keep the original README file or, at least, provide a link to the original Genode repository.
- Have you tried to run your GUI application on base-linux? If yes,
have you compared its performance to the same application compiled for native Linux w/o Genode? Our apps is Fiasco.OC-specific, so I don't know how to run these apps on base-linux.
- On base-linux, you could use normal Linux profiling tools such as
oprofile to find out where the CPU time goes. Please recommend some similar tools on base-foc.
There is no such tool for base-foc. For this reason, I recommended to run the application on base-linux in the first place.
Even if you application depends on Fiasco.OC, you might still use any of the other (portable) example applications to investigate an eventual performance problem of Qt. First check if the behavior that you noticed can be reproduced with one of those example applications. If that is the case, run the same application on Linux and use oprofile to investigate.
- Can you make a Git branch with your application publicly available
https://github.com/kloisiie/vsos%E2%80%8D To run the vsos, use $ ./create_builddir fox_x86_32 build_dir=~/<build-directory> to create a build directory, and then execute $ make run/verify in build directory.
Unfortunately, I am not able to compile it. I get an error as follows:
/open/incoming/vsos/base/include/base/rpc_server.h:152:41: error: ‘l4_utcb_id’ is not a member of ‘Fiasco’
The type 'l4_utcb_id' does not exist in the 'base-foc/contrib' source tree. It seems like you changed the kernel but invoking 'make prepare' within 'base-foc' fetches the original kernel.
Best regards Norman
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#...
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
Hello Norman,
I'm sorry for my carelessness.
L4_UTCB_USER_ID_OFFSET is defined in
\base-foc\contrib\l4\pkg\l4sys\include\ARCH-x86\utcb.h
as
L4_UTCB_USER_ID_OFFSET = 62 * sizeof(l4_umword_t),
Shuo Wang, University of Chinese Academy of Sciences.
------------------ Original Mail ------------------ "norman.feske";<norman.feske@...1...>; "genode-main"genode-main@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#...
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
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@...1...>; 2014-09-06 7:12 pm "genode-main"genode-main@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#...
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
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
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@...1...>; 发送时间: 2014年9月10日(星期三) 晚上6:34 收件人: "genode-main"genode-main@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
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@...1...>; 发送时间: 2014年9月10日(星期三) 晚上6:34 收件人: "genode-main"<genode-main@...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.cl... _______________________________________________ genode-main mailing list genode-main@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.cl... genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Shuo,
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.
your observation surprises me. We have recently compared the performance of Arora (using Qt5, not Qt4!) running on the Pandaboard by measuring page-load times of large websites like spiegel.de. We found that Arora running on the base-hw kernel was actually faster than Arora running on the current version of Ubuntu Linux.
Have you considered to cross-correlate the performance issues using different kernels? E.g., running the qt5.run script on NOVA instead of Fiasco.OC? Some workloads are known to be extremely slow on Fiasco.OC. See [1] for more details.
[1] https://github.com/genodelabs/genode/issues/712
Also, it might be worth considering to test the scenarios on a different hardware platform and revisit the BIOS settings for power-management.
Finally, I'd like to reinforce what Vasily just said. Please provide us with a metric for "good" performance.
Best regards Norman
-
unknown＠example.com -
Norman Feske -
Sartakov A. Vasily -
王硕