Interaction with L4
peter.nguyen at ...29...
Tue Jan 19 23:46:16 CET 2010
> I know too little about the structure of your profiling environment
> to give a clear advice on how to integrate it with Genode. The answer
> depends on the relationship between the user-level portion of your
> profiling environment and the other processes. If there is no
> interaction (only interaction with the kernel) and the profiling
> takes place at a global level (e.g., monitoring the IPC traffic
> between all processes), the profiling process could be started just
> alongside the other programs by the init process. But I assume that
> the profiling environment somehow has to interact with the rest of
> the system, for example for presenting the profiling result or
> for getting activated in the first place.
My profiling environment makes use of sampling, where samples are taken of the
system execution. These samples are generated in the microkernel as they are
based on the timer interrupt within the kernel. The samples are then copied to
buffers in user space. Basically, the data that can be collected only pertains
to kernel "related" information. If I had more time with my project (which is a
Masters project), I would have provided more functionality pertaining to
user-space functionality. At this time though, I only really want to focus on
the network functionality with regards to experimentation.
> Another setting would be to apply profiling as a tool to analyse
> a Genode subsystem only. This could be achieved by letting the
> profiler play the role of the parent of this subsystem (similar
> to init). This way, all requests of the subsystem to the outside will
> become visible to the profiler at the Genode API level. For example,
> if the subsystem creates a new process, it will ask the parent
> (which is then the profiler) to create the corresponding CPU, PD,
> and RAM sessions. So the profiler can observe how the subsystem
> interacts with the outside and, in principle, virtualize all services
> used by the subsystem, or just delegate requests further to the
> profiler's parent. This way, the profiler could obtain much higher
> level information about the system than plain kernel events.
That would be very useful for profiling Genode, but as I mentioned before, I
don't really have any time to consider this.
> Can you elaborate why the profiling code is tied to L4? Would it be
> possible to generalize it? I ask because a general profiling infra-
> structure would be valuable not only on OKL4 but also on the other
I am very aware that generalising my profiling infrastructure would be very
valuable, but time constraints prevent me from doing such work. My
implementation of the profiling environment was only based on L4/Iguana, and
using Wombat as part of testing. I have been looking into Genode as of late due
to the other functionality that is already available eg. HTTP server. Also, I
figured that porting the user-space portion should be relatively easy to do,
since all i would need to worry about is copying the samples to user space. I'm
assuming here that Genode is similar to Iguana, but with significantly more
functionality than Iguana.
More information about the users