l4-hackers June 2001

l4-hackers@os.inf.tu-dresden.de

10 participants
10 discussions

Re: L4-Linux as a real-time OS
by Michael Hohmuth 29 Jun '01

29 Jun '01

"Jun-ichi Odagiri" <jun-ichi.odagiri(a)kek.jp> writes: > [...] The essential point, for my application, is that the both > types of clients must work in a single user address space, i.e. they > must be user-level threads, which are to be created through the > Linux clone() system call. Please note that currently L4Linux puts threads started by clone(...CLONE_VM...) into different L4 tasks. They will have the same memory view, but they use different address spaces as far as L4 is concerned. In other words, the L4Linux page table is shared, but L4's isn't. > In standard Linux, a process does not cause page faults once it has > invoked the mlockall() system call. It does not apply to L4Linux since > you have two different sets of page tables for an L4Linux client. One in > the Linux server, and the other in the L4 kernel. The former is filled once > mlockall() has invoked. However, the latter is left unchanged even after > mlockall() returns. Page faults are still needed just to update the page > tables in the L4 kernel. As you pointed out in the above 1, my real-time > L4Linux client must not do Linux system calls, nor page faults. There is an additional problem. Suppose your program shares pages with another process (e.g., a shared-library text segment) and the L4Linux needs to flush these page mappings for the other process. In that case, L4Linux calls l4_fpage_unmap(fpage, L4_FP_OTHER_SPACES). This call results in the shared page being flushed not only from the other task's address space, but also from your address space. You will have to remap it on page fault. I don't quite remember all cases L4Linux would have to do that, but I seem to remember that it happens when a process is killed: L4Linux needs to flush all mappings a dying task owned. As there is no way for L4Linux to tell if a task had granted away some pages, a simple task deletion is not enough; L4Linux must flush all mappings separately. For this reason (no way to prevent granting), the L4 API currently does not have a primitive for flushing a page only in a specific address space. In consequence, L4Linux needs to flush all client mappings at once. A possible extension of the L4 API would provide these two mechanisms. A possible workaround for you might be to just disable the flushing at task-delete time (Jean or Frank probably could tell you what to change), although, as I said, I don't remember if there are other places that flush mappings. > So, I made a Linux system call that makes the Linux server fill the page > tables of the calling L4Linux client in the L4 kernel. In order to implement > the Linux system call, I had to add an L4 system call, l4_fpage_map(), > which allows an L4 task (the Linux server) to send a flex page to another > L4 task (an L4Linux client) without the recipient's agreement. I believe > you do not like it because it harms the security of the system. But, being > a control system, it's still acceptable by me (may be...). You could do without the L4-kernel modification if your L4Linux system call just toggled a flag that told L4Linux to map the whole address space (l4_fpage(...L4_WHOLE_ADDRESS_SPACE...)) to the current process on page-fault. Subsequently, your client can ``forge'' a page-fault message to the L4Linux server. > >See <URL:http://os.inf.tu-dresden.de/papers_ps/part98.ps> for a > >description of the implementation. > > I failed in openning the .ps file on my system. I'll try it later again. I had no problem in downloading and opening the file, so it probably is a transient problem. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

3 2

Re: L4-Linux as a real-time OS
by Michael Hohmuth 27 Jun '01

27 Jun '01

"Jun-ichi Odagiri" <jun-ichi.odagiri(a)kek.jp> writes: > I've been trying to use L4-Linux as a real-time platform for a control > application. [...] > 1) Is that kind of idea crazy? Not at all! > 2) Is there anyone who tried (or is going to try) something like that? We often use setups similar to the one Frank described (external L4 task doing real-time work, L4Linux runs a timesharing load) for research purposes. I am not aware of anyone who used L4Linux clients for real-time work, but the idea is interesting. I see that L4Linux clients are easier to develop and debug. However, Frank recently finished an L4-task loader for L4Linux that regains some of Linux' convenience for L4 development. > 3) Is L4-Linux going to keep up with the revisions of Linux in the > future? We certainly plan keeping L4Linux up-to-date, but I cannot make any promises. It's a matter of demand (both by ourselves and by others) and resources. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: L4-Linux as a real-time OS
by Michael Hohmuth 27 Jun '01

27 Jun '01

"Jun-ichi Odagiri" <jun-ichi.odagiri(a)kek.jp> writes: > On Friday 15 June 2001 8:49 PM, Frank Mehnert wrote: > >You should not expect any real-time behavior if you use a L4Linux task > >to serve interrupts. > > Here, you mean a "process of L4Linux" by the word "L4Linux task", wright? Yes, he does. Below, I will use the term L4Linux client to avoid confusion. > >Instead of this, implement the time-critical code (e.g. I/O to VME board, > >computations of output values) in an L4 task. > > I'm aware that your suggestion is the right way. Still, it is > convenient for me if a "process" can be used to serve interrupts in > my application. I guess your "an L4 task" can be a "process" of > L4-Linux if it has a priority higher than that of the Linux server > task, am I right? I noticed that a process can cause page faults > even after it has called "mlockall" to make itself > memory-resident. I've taken care of this. You're right in principle, but there are some obstacles. 1. Obviously your real-time L4Linux client must not do Linux system calls. 2. How do you increase the L4 priority of your program? In an L4Linux client you can't because it has an MCP (maximum controlled priority) of 0. You need to implement an L4Linux driver or a program external to L4Linux (an "L4 task") to increase your client's priority. 3. As you noticed, mlockall() makes the program memory-resident, but doesn't prevent page faults: When L4Linux kills an L4Linux client, it flushes some pages from all clients' address spaces (which these clients need to map in again upon the next page fault). You said you've taken care of this problem. How? One solution would be to use an external memory manager (an L4 task) that provides nonpageable memory. > >Then you will get worst-case latencies of about 85 microseconds (P800). > > The worst-case interrupt latency I got was roughly 700 microseconds. > What dominates the latency in L4-linux is not the performance of L4 > (I'm using Fiasco, actually) but the critical sections of Linux, > which are executed with disabling interrupts. RT-linux people found > that standard Linux disables interrupts as long as 600 > microseconds. It applies to the Linux server task of L4-Linux as > well, I guess. I'm thinking of replaceing the "interrupts off" with > another method to achieve required mutual exclusion. Then, I will > get the number you suggested, hopefully. This is exactly the problem the "tamed server" option Frank recommended solves: > >Note that you should use the tamed version of L4Linux (make menuconfig - > >"L4Linux options" - "Use tamed server"). > > I'm going to check what the option does. Still, I was wondering if > you could explain the point to me. See <URL:http://os.inf.tu-dresden.de/papers_ps/part98.ps> for a description of the implementation. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: Fiasco Status
by Michael Hohmuth 18 Jun '01

18 Jun '01

COFFMAN Steven <SCoffman(a)COVANSYS.com> writes: > Sorry if this was mentioned previously, but the status page for Fiasco > (October 2000) mentions that Fiasco still doesn't have Flex I/O pages. Is > this still the case with CVS? I/O flexpages still are not implemented. Unfortunately, implementing it is not a top priority for us right now (as Fiasco and L4 mostly are used in research contexts), but it still would be nice to have. The priorities could change if an external user shows significant interest. We are currently looking for a student or a contributor to implement this feature. I believe it's not that difficult to do. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

3 2

Re: Fiasco Status
by Michael Hohmuth 18 Jun '01

18 Jun '01

Christian Stueble <stueble(a)cs.uni-sb.de> writes: > I am very interested in I/O flexpages and a working clans & chiefs > concept to be able to improve the Perseus secure operating system > project. (http://www.krypt.cs.uni-sb.de/~perseus). And I have some > students here which are interested in practical jobs. But of course > they are more interested in security than in operating systems. Do > you think that it would be possible to implement this features at > the time of a software practical (about 6 month 6 h/week)? Yes, I think so. However, if your student does not have an operating-systems background, she or he needs to be willing to dive into all of the IA32 reference manual, the L4 reference manual, and the Fiasco source code, or at least keep in touch with someone who has experience with these things. There are three areas of work for Fiasco: - Memory representation of the I/O-port--access bitmap - I/O-flexpage--mapping IPC - Mapping-database support for I/O addresses On user level, at least these programs need to be adapted to use I/O flexpages: - L4Linux - RMGR > Another (maybe simpler) approach to prevent hardware access would be > to allow the RMGR to completely decide whether subtasks are allowed to > access I/O ports or not (e.g. configured in the config-file). This allows us > to implement a trusted server task which executes these operations while > enforcing a security policy. Of course this would be slower etc..... For such a protocol, simple controlled inheritance of the I/O- privilege level would suffice. However, with it it's impossible to allow privileged, unmodified Linux programs (such as the X server) to access ports. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: Questions: porting, L4Linux status and performance.
by Michael Hohmuth 17 Jun '01

17 Jun '01

Martin Young <my(a)siroyan.com> writes: > I'm interested in putting L4 on a 'new' processor core [...]. Cool! Can you elaborate on why you're interested in doing this? > Is there a recommended route for doing this? I suppose that I could > either write a new implementation from scratch or port an existing one. > L4Ka looks quite attactive as it already exists for more than one > platform and it's available under the GPL. OTOH the L4/x86 reference > manual is so short that a new implementation doesn't look too daunting. > Would anybody like to guess how long either route would take? (Take the following with a grain of salt: I am the main designer and implementor of the Fiasco microkernel.) In the past, no L4 implementation has ever been reused and ported to a different architecture by a group other than the originator's. It has been the L4 gospel that it is cheaper to just do a new implementation. This has worked well so far. I estimate the cost to be somewhere between .5 and 1.5 man years, depending on the level of sophistication you want to achieve (real-time? SMP?) and the tests you have (on the x86 we have L4Linux; when L4Linux stops crashing, you're done ;-). AFAICT, one of the goals of the L4KA project is to prove that a portable L4 implementation is both possible and feasible. I believe that the L4KA hackers can put their kernel on a new architecture in a matter of weeks. However, I have no idea how approachable their source code is or whether they have any design documentation or implementation notes available. If they have something, though, I'm certain they'd be happy to share it with you. (They are actively researching microkernel portability. Maybe they'd even like to hire you!) Strictly speaking, Fiasco has been developed for x86 CPUs without special regard to portability. However, Fiasco's object-oriented design encapsulates hardware specifics as much as other subsystems. I believe that it can be refactored quite easily to support more than one architecture. Therefore, I personally would look into porting Fiasco. Of course, I'm in a better position that you are, because I am well accustomed with this beast, but I believe that Fiasco's structure is quite intelligible if you are a bit into OO design. I also have some design documentation available for the asking. I and my group would be happy to help out with our experience. That said, I believe that both options for porting an existing kernel do not take significantly shorter than just doing it yourself, given you don't know the source base. Just like developing a new system, porting a kernel requires understanding it, and that can take time. > I'm also wondering how stable L4Linux (particularly the 2.2.x kernel > version) actually is. I see on the mailing list that some simple > commands can crash the kernel, but is this typical? I don't want to run > anything large like a RH distribution but a stable kernel+bash would be > great. No, this is not typical. L4Linux is quite stable and happily boots Linux to multiuser mode and runs XFree86, Netscape, XPilot and the likes. > If I were to write or port an L4 MK I expect that initial versions > wouldn't be well optimised for my CPU architecture. In this situation > how would it's performace compare to (for example) mach?

3 2

L4-Linux as a real-time OS
by Jun-ichi Odagiri 16 Jun '01

16 Jun '01

Hello, I've been trying to use L4-Linux as a real-time platform for a control application. The application was developed based on VxWorks, but ported to Linux lately. Unfortunately, as you know, Linux allows usual processes to block a real-time process for durations of 100 ms or more. I found that a process of L4-Linux can preempt the Linux server if the process is given a priority higher than that of Linux, and can continue with its work as far as it does not call Linux for services. I actually tested it on a PC-compliant VME CPU board. Interrupt latency in the worst case was less than 1 ms, even with a disk I/O background. I'm wondering if this mailing-list accepts application related issues as well. If so, I'd like to ask you : 1) Is that kind of idea crazy? 2) Is there anyone who tried (or is going to try) something like that? 3) Is L4-Linux going to keep up with the revisions of Linux in the future? I'll appreciate any suggestion, comment and criticism. Thanks in advance. J. Odagiri

2 2

RE: L4-Linux as a real-time OS
by Sebastian Schoenberg 15 Jun '01

15 Jun '01

> > You should not expect any real-time behavior if you use a L4Linux task > to serve interrupts. Instead of this, implement the time-critical code > (e.g. I/O to VME board, computations of output values) in an L4 task. > Then let this task communicate with L4Linux by IPC (usually by using > an own thread). > > Then you will get worst-case latencies of about 85 > microseconds (P800). A quick note: This relatively high number is not due to a bad implementation of the kernel itself. It is the result of a bunch of impacts such as TLB misses, cache misses for data, code and cache misses on parsing page tables, etc... Sebastian

1 0

Fiasco Status
by COFFMAN Steven 15 Jun '01

15 Jun '01

Sorry if this was mentioned previously, but the status page for Fiasco (October 2000) mentions that Fiasco still doesn't have Flex I/O pages. Is this still the case with CVS? -Steve

2 1

Questions: porting, L4Linux status and performance.
by Martin Young 13 Jun '01

13 Jun '01

Hi Folks, I've had a look around the L4 web site and I've got a few questions... I'm interested in putting L4 on a 'new' processor core (although strictly as an unofficial spare-time activity). I have experience of porting Chorus to two different cores and I've done various other mk-related stuff so I wouldn't be going in entirely cold. Is there a recommended route for doing this? I suppose that I could either write a new implementation from scratch or port an existing one. L4Ka looks quite attactive as it already exists for more than one platform and it's available under the GPL. OTOH the L4/x86 reference manual is so short that a new implementation doesn't look too daunting. Would anybody like to guess how long either route would take? I'm also wondering how stable L4Linux (particularly the 2.2.x kernel version) actually is. I see on the mailing list that some simple commands can crash the kernel, but is this typical? I don't want to run anything large like a RH distribution but a stable kernel+bash would be great. If I were to write or port an L4 MK I expect that initial versions wouldn't be well optimised for my CPU architecture. In this situation how would it's performace compare to (for example) mach? Does L4's performane advantage come from optimisation of the implementation or from its architecture? The literature suggests the latter however I note that many L4 implementations are written in assembler and that there are performance concerns about Hazelnut. Thanks. -- Martin Young, working for: | Phone: +44(0) 1454 615151 Siroyan Limited, Bristol Design Centre, | Mobile: +44(0) 7855 758771 West Point Court, Great Park Road, | web: www.siroyan.com Bradley Stoke, Bristol BS32 4QG. UK | email: my(a)siroyan.com ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers June 2001