users March 2013

users@lists.genode.org

17 participants
16 discussions

Low performance of L4Linux network
by Ivan Loskutov 20 Mar '13

20 Mar '13

Hello there. I've tested network performance of L4Linux network on real hardware and have not good results http://ksyslabs.org/doku.php?id=genode_network_perfomance Performance is very low. Do you have any ideas how to increase it? -- Ivan Loskutov

1 0

Conquering NUMA land
by Norman Feske 19 Mar '13

19 Mar '13

Hello, I got repeatedly asked about our plans to scale Genode towards hardware platforms with non-uniform memory architectures (NUMA), i.e., manycore systems. This posting is meant as a rough collection of ideas. It is not an immediate call for action, nor an actual plan. But maybe it will spawn a worthwhile discussion on the subject, so that we can develop a tangible way forward together. Until now, multi-core platforms have not received much attention by Genode because the framework has primarily been used on hardware with only a few CPU cores and the work loads carried by the framework had been relatively light-weight. This manifests in the current state of the implementation. For example, on Fiasco.OC, we use a single pager thread within core to resolve all page faults in the system, which implies costly inter-processor interrupts (IPI) when page faults occur on CPUs that are remote to the pager thread. As another example for current deficiencies, several data structures within core are accessed in a serialized fashion. If threads of different CPUs need to access those data structures concurrently, those points of contention naturally become scalability bottlenecks. Concurrent page-fault handling ------------------------------ On a multi-core system, CPU-local page fault handling is desired. Genode's core-internal page-fault handling could be changed relatively easily to a model where we use one page-fault handler per CPU. This way, the delivery of page-fault messages would not involve any IPIs. I think that this step is clearly beneficial. On NOVA, we already employ a scheme where each thread has a dedicated page-fault-handler in core. So we have already implemented the fine-grained synchronization of the data structures within core needed for that. Here, page faults caused by different threads are effectively handled in parallel. (we are not using multiple CPUs no NOVA yet, though) Applying a similar scheme to other kernels such as Fiasco.OC would be a relatively small step. However, the page-fault handlers would still operate on the shared data structures such as the allocator for physical memory or RM sessions. So synchronization of those data structures is needed. To completely localize PF-handling and remove synchronization between different CPUs, we would need to localize data structures as well. This is a much harder problem, which can be tackled by replicating data or partitioning. Both approaches will ultimately increase the complexity of Genode's core and also introduce the need to feed core with platform parameters and policies. This is something that I'd like to avoid. After all, the low complexity of the Genode base system is one of its strongest points. Challenges of NUMA ------------------ When looking a step further, to NUMA systems, we will further find that we also need to localize code. For example, the code and data that is involved in executing the page-fault handling should always be close to the core on which the faulting thread is running. With this in mind, the system will get even more complicated. These observations make me hesitant to extend core beyond the basic implementation of the multi-threaded page-fault handling. VCore - Virtualizing Genode's core ---------------------------------- However, I see an alternative way, which is actually pretty similar to the concept employed in Barrelfish: Co-hosting multiple loosely coupled subsystems on one machine. We could try to leverage Genode's recursive nature to solve the problem atop of core by introducing CPU-local branches of the Genode process tree. The basic idea would be to virtualize core's CPU, RAM, and RM services by using a new component (let's call it vcore for now). Any number of vcores can run at a time whereas each vcore is responsible for a set of physical CPUs and their associated CPU-local memory resources. Each vcore is a runtime environment that can be supplied with a configuration that describes the subsystem to execute, similar to Genode's init process. In addition, the configuration comes with the information about the physical CPUs and memory ranges that the vcore instance should manage. For all Genode components running on top of a vcore instance, its respective vcore instance looks just like core. When a vcore instance is started, it will read its configuration to obtain the ranges of physical RAM it should manage. It will then allocate the those ranges at core and map (and fault-in) them locally. This step may be slow but it is done only once at the startup of vcore. So basically, the vcore instance is sucking out all the RAM that belongs to its resource partition from core. With the current interface of Genode's core, this is not possible. So we need to slightly extend core to accommodate this use case. When starting its children, vcore will not hand out core's RAM and RM sessions to the child but implement those services itself. So each time a process of the subsystem performs a RAM allocation or attaches a dataspace to its RM session, those requests will be handled and monitored by vcore. By virtualizing the RM session, vcore can furthermore hook-in itself as the page-fault handler of those processes. Hence, page faults are always handled locally by the corresponding vcore. On Genode, the page-fault handling is actually a library, which principally allows for processing page-fault handling outside of core (although we have never attempted to use this library outside of core so far). So this idea seems feasible to me. Now, with handling page faults local to each vcore, we naturally eliminate cross-CPU talk. However, we need to consider cases where a process inside a vcore environment wants to access a dataspace provided by a process outside of its vcore, for example, when using a resource multiplexer such as the nitpicker GUI server. In this case, vcore is unable to resolve the page fault because it has not created the corresponding dataspace (it was created by nitpicker using core's RAM service). However, there is always the real core underneath all vcore's, which has a complete view of the system. So vcore could forward such non-vcore-local page-faults to core. Nifty, isn't it? Naturally, such non-local page faults will carry an overhead by taking a hop though vcore. But access to those non-local resources is expected to be slow (and rare) anyway. There is still one constellation that cannot be accommodated this way, which is the direct sharing of dataspaces between different vcores. Is this feasible? ----------------- Right now, the vcore idea is just a rough sketch. Admittedly I cannot give a substantial estimate on how successful it may be as I am lacking the experience in the domain of manycore systems, nor do I have access to a large NUMA machine. So I hope that someone of you may step in to share actual experiences or to point out flaws with this idea. I already see a few limitations. For example, even though the vcore idea looks like a nice solution for the problem space covered by Genode, there are problems lying outside the scope of Genode that may severe impede the system's scalability even if the concept works out as desired, namely the kernel. The kernel needs to address the CPU locality problem for its own operations, in particular IPC, too. How to go about that problem? Apart from that, I see additional challenges related to devices, such as the CPU-local handling of device interrupts or the access of MMIO device resources. However, if going for the vcore concept, I see plenty of topics that could be pursued building upon that, for example the implementation of dynamic load balancing, or dynamically changing vcore policies, or extending vcore for power management. What do you think? Would the vcore idea be worthwhile to explore? Those of you experienced in the field of manycore NUMA systems, do you see additional pitfalls? Or even better, does anyone has alternative ideas to explore? Also, I am very interested in ways to validate work in this domain. How can we measure our success? 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

3 5

Issue in run/demo using foc_imx53 biuld directory
by vamsi krishna 18 Mar '13

18 Mar '13

Hi, I wanted to build Fiasco microkernel for imx53 board. i downloaded the genode-13.02. I created the build directory by using the following command. ./tool/create_builddir foc_imx53 BUILD_DIR=build After that when i am trying to run following command $ make run/demo i got the following error Library timer COMPILE main.o In file included from /home/vamsi/genode-13.02/os/src/drivers/timer/include/timer_session_component.h:26:0, from /home/vamsi/genode-13.02/os/src/drivers/timer/include/timer_root.h:23, from /home/vamsi/genode-13.02/os/src/drivers/timer/main.cc:19: /home/vamsi/genode-13.02/os/src/drivers/timer/hw/platform_timer.h: In member function ‘long unsigned int Platform_timer::curr_time() const’: /home/vamsi/genode-13.02/os/src/drivers/timer/hw/platform_timer.h:63:41: error: passing ‘const Platform_timer’ as ‘this’ argument of ‘long unsigned int Genode::Epit::value(bool&)’ discards qualifiers [-fpermissive] /home/vamsi/genode-13.02/os/src/drivers/timer/hw/platform_timer.h:65:55: error: passing ‘const Platform_timer’ as ‘this’ argument of ‘long unsigned int Genode::Epit::max_value()’ discards qualifiers [-fpermissive] /home/vamsi/genode-13.02/os/src/drivers/timer/hw/platform_timer.h:72:43: error: passing ‘const Platform_timer’ as ‘this’ argument of ‘long unsigned int Genode::Epit::tics_to_us(long unsigned int)’ discards qualifiers [-fpermissive] make[3]: *** [main.o] Error 1 make[2]: *** [timer.lib] Error 2 make[1]: *** [gen_deps_and_build_targets] Error 2 make[1]: Leaving directory `/home/vamsi/genode-13.02/fiasco' Error: Genode build failed make: *** [run/demo] Error 252 Regards, S. Vamsi Krishna, 2nd Year M.Tech | CSE, Network Systems Lab, IITM.

3 2

Physical memory allocation.
by Daniel Waddington 18 Mar '13

18 Mar '13

Hi, For the purpose of NUMA based memory management, I would like to have Genode allow me to allocate physical memory at a specified address, i.e., support something like... |||||||||virtual| ||Ram_dataspace_capability ||alloc||_at(|||size_t ||size|||, addr_t start_address, |||bool ||cached|| |=| true|)||| ||=| 0|; I figure I can temporarily hack this by extending Ram_session_component::alloc and using Range_allocator::alloc_addr. Is there any danger here? Can Genode be persuaded to extend the main line to support this? An address range parameter instead of start address would be even better, i.e., try to allocate me some RAM somewhere between physical address X and Y. Best, Daniel |||||||

2 1

error in make run/l4linux on fiasco.oc
by yuqing wang 12 Mar '13

12 Mar '13

hi i want to get the l4linux running.i followed the step according to source tree file --genode/base-foc/doc/foc.txt.i did make prepare in 'ports-foc' and 'dde_ipxe' repository in genode source tree. i edited the 'etc/build.conf' file in my build directory,and uncomment the following line : REPOSITORIES += $(GENODE_DIR)/dde_ipxe REPOSITORIES += $(GENODE_DIR)/ports-foc i downloaded the 'inird.gz' file and resided it in 'bin' in my build directory. i thought i did everything well, but when i make run/l4linx ,there comes a issue,here is the message: using run script /home/wangyuqing/下载/genode/base-foc/run/env using run script /home/wangyuqing/下载/genode/ports-foc/run/l4linux.run building targets: core init drivers/timer drivers/uart drivers/framebuffer l4linux drivers/nic drivers/pci drivers/input/ps2 spawn make core init drivers/timer drivers/uart drivers/framebuffer l4linux drivers/nic drivers/pci drivers/input/ps2 make[1]: 正在进入目录 `/home/wangyuqing/下载/genode_focx86_builddir' checking library dependencies... Skip target core/arndale because it requires arm foc_arndale Skip target core/imx53 because it requires arm foc_imx53 Skip target core/panda because it requires arm foc_panda Skip target core/pbxa9 because it requires arm foc_pbxa9 Skip target core/vea9x4 because it requires arm foc_vea9x4 Skip target drivers/framebuffer/fiasco_ux because it requires fiasco Skip target drivers/framebuffer/omap4 because it requires omap4 Skip target drivers/framebuffer/pl11x/pbxa9 because it requires pl11x platform_pbxa9 Skip target drivers/framebuffer/pl11x/vea9x4 because it requires pl11x platform_vea9x4 Skip target drivers/framebuffer/pl11x/vpb926 because it requires pl11x platform_vpb926 Skip target drivers/framebuffer/sdl because it requires linux sdl Skip target drivers/input/ps2/pl050 because it requires pl050 Skip target drivers/nic/lan9118 because it requires lan9118 Skip target drivers/nic/linux because it requires linux Skip target drivers/pci/device_pd because it requires nova Skip target drivers/uart/omap4 because it requires omap4 Skip target drivers/uart/pl011 because it requires pl011 Skip target l4linux/arm because it requires arm Program drivers/framebuffer/pl11x/ Library platform Library cxx Library syscall Library startup Library base-common Library base Library blit Program drivers/framebuffer/vesa/vesa_drv Program drivers/input/ps2/x86/ps2_drv Library alarm Library dde_kit Library dde_ipxe_support Library dde_ipxe_nic Program drivers/nic/nic_drv Program drivers/pci/x86/pci_drv Library timer Program drivers/timer/timer Program drivers/uart/i8250/uart_drv Library init_pd_args Program init/init Library l4lx Library l4sys Program l4linux/x86_32/vmlinux make[6]: 没有什么可以做的为 `all'。 =============================================== For quick build instructions, please visit: http://wiki.tudos.org/Quickstart http://l4linux.org/build.shtml =============================================== make[6]: 没有什么可以做的为 `all'。 Using /home/wangyuqing/下载/genode/ports-foc/contrib/l4linux as source for kernel GEN /home/wangyuqing/下载/genode_focx86_builddir/l4linux/Makefile CHK include/linux/version.h CHK include/generated/utsrelease.h CALL /home/wangyuqing/下载/genode/ports-foc/contrib/l4linux/scripts/checksyscalls.sh CHK include/generated/compile.h LINK vmlinux LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o KSYM .tmp_kallsyms1.o KSYM .tmp_kallsyms2.o LD vmlinux SORTEX vmlinux sort done marker at 399e58 SYSMAP System.map OBJCOPY arch/l4/boot/Image Kernel: arch/l4/boot/Image is ready Building modules, stage 2. MODPOST 98 modules WARNING: modpost: Found 1 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' Program core/x86/core make[1]:正在离开目录 `/home/wangyuqing/下载/genode_focx86_builddir' genode build completed using fiasco kernel /home/wangyuqing/下载/genode_focx86_builddir/kernel/fiasco.oc/fiasco using sigma0/bootstrap at /home/wangyuqing/下载/genode_focx86_builddir/l4 creating ISO image... spawn qemu-system-i386 -no-kvm -m 128 -nographic -serial file:kdb.log -serial mon:stdio -smp 2,cores=2 -net nic,model=e1000 -net user -cdrom var/run/l4linux.iso Error: Test execution timed out make: *** [run/l4linux] 错误 254 how can i fix it Regards

3 4

Issue in make run/demo
by yuqing wang 10 Mar '13

10 Mar '13

Hi I am new in Genode.I downloaded genode and genodetoolchain fromhttp://genode.org/download<http://genode.org/download/tool-chain>. After I followed the step according to http://genode.org/documentation/developer-resources/getting_started , I was getting a issue. I followed the step to build genode for linux.After make run/demo,these message was shown: spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 4095 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init -> launchpad] Could not open file "ld.lib.so" [init -> launchpad] Could not open file "config" [init -> launchpad] Could not obtain config file [init -> timer] args='label="nitpicker", ram_quota=4096' [init -> fb_sdl] creating virtual framebuffer for mode 1024x768@...64... [init -> nitpicker] framebuffer is 1024x768@...23... [init -> nitpicker] create session with args: fb_format=1, label="launchpad", ram_quota=1646592 [init -> nitpicker] Could not open file "config" [init -> nitpicker] Could not obtain config file [init -> nitpicker] create session with args: fb_width=400, fb_height=1504, fb_format=1, label="launchpad", ram_quota=1211392 [init -> timer] args='label="launchpad", ram_quota=4096' [init -> launchpad] --- entering main loop --- It seemed that something was wrong, but it did work.I am getting the GUI. But when i contiued the experiment--build genode for fiasco,almost same message was shown,but i got no GUI. int main(): --- create local services --- int main(): --- start init --- int main(): transferred 229 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init -> ps2_drv] Detected ExPS/2 mouse - activating scroll-wheel and 5-button support. [init -> ps2_drv] Using keyboard with scan code set 1 (xlate). [init -> pci_drv] PCI driver started [init -> pci_drv] Could not open file "pci_device_pd" [init -> pci_drv] PCI device protection domain for IOMMU support is not available [init -> vesa_drv] int Framebuffer_drv::map_io_mem(Genode::addr_t, Genode::size_t, bool, void**, Genode::addr_t, Genode::Dataspace_capability*): fb mapped to 106a000 [init -> pci_drv] Could not open file "config" [init -> pci_drv] Could not obtain config file [init -> pci_drv] PCI config space data could not be parsed. [init -> launchpad] Could not open file "ld.lib.so" [init -> launchpad] Could not open file "config" [init -> launchpad] Could not obtain config file [init -> timer] args='label="nitpicker", ram_quota=4096' [init -> vesa_drv] Could not open file "config" [init -> vesa_drv] Could not obtain config file [init -> vesa_drv] Found: VESA BIOS version 2.0 [init -> vesa_drv] OEM: VGABIOS Cirrus extension [init -> vesa_drv] Found: physical frame buffer at 0xfc000000 size: 0x00400000 [init -> vesa_drv] int Framebuffer_drv::map_io_mem(Genode::addr_t, Genode::size_t, bool, void**, Genode::addr_t, Genode::Dataspace_capability*): fb mapped to 400000 [init -> nitpicker] framebuffer is 1024x768@...23... [init -> nitpicker] create session with args: fb_format=1, label="launchpad", ram_quota=1646592 [init -> nitpicker] Could not open file "config" [init -> nitpicker] Could not obtain config file [init -> nitpicker] create session with args: fb_width=400, fb_height=1504, fb_format=1, label="launchpad", ram_quota=1211392 [init -> timer] args='label="launchpad", ram_quota=4096' [init -> launchpad] --- entering main loop --- Is this right?I am not sure whether it really has no GUI to show or i made some mistakes. I am using ubuntu 12.04 LTS. regards kukar

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users March 2013