October 2002 - l4-hackers - example.com Site

RE: Re[8]: performance of L4Linux
by Volkmar Uhlig 29 Oct '02

29 Oct '02

> As far as I understand you want to find out whether: > - mklinux is really as bad as published > - L4Linux is really as fast as published > > Start with the first one. > > Then fetch a version of L4 from l4kabuild l4linux 2.0 against it and > try to find out about the second point. (I don't know whether l4ka's > version supports 4Mb pages and small address spaces but you will find > out whether they do or not) Hazelnut supports small spaces. We published a TR about the performance of small spaces for the P4 architecture using an L4Linux environment. See also: http://i30www.ira.uka.de/research/publications/ Actually, the relative syscall overhead using an adopted glibc was lower than the original numbers given by the SOSP paper. We ran L4Linux and the applications in small spaces. (Hazelnut supports different configurations for small spaces -- up to 2GB for the small space area.) - Volkmar

1 0

Re[4]: performance of L4Linux
by Igor Shmukler 29 Oct '02

29 Oct '02

> Well, then you should probably start reading the publications about L3 > and L4 of the last 7 years and you will find an in-detail analysis why > your statement could be taken as offensive rant... ;-) There are pretty > exact numbers of MACH's cache utilization and performance of IPC and the > structural problems of the communication mechanism. Well, I have done that (read papers). Cache utilization is very easy to fix. In fact when I did Mach VM overhauling (couple of years ago) it maybe took me one day to implement coloring. IPC issue was not discovered by l3/4 team, but rather was known issue for very long time. There are much older Utah and UW papers that address that. Anything else l3/4 team has up the sleeve? If I was to say that being tightly architectutre coupled is strange or that since l4 took almost everything out of the kernel, memory management could have been evicted as well (like eros microkernel does), then you may need to get offended. Otherwise, I don't see your point. L4 papers states that since there is no way to prove that Mach only causes 5% degradation statement is not valid. I say same logic applies to MkLinux vs. L4Linux. I am not trying to start am flame war. Nor do I claim that L4 is worthless. I simply want to see if there is a way to validate specific statement. If there is, that means that statement is valid, if there is not, then you tell me ... As simple as that. IS.

2 5

RE: Re[6]: performance of L4Linux
by Volkmar Uhlig 29 Oct '02

29 Oct '02

Just out of curiosity -- where do you want to get the not publicly available L4 x86-assembly kernel from to actually being able to redo the measurements? It is intellectual property of a company and not downloadable anywhere. Furthermore, if you redo the measurements on different hardware and you read the "On mk construction" paper you should know that MKs (at least L4 MKs) are highly optimized for one particular architecture. Hence, even when having the kernel and running it on different hardware your numbers are bogus and do not state anything except that you get a set of more numbers...

3 2

RE: Re[8]: performance of L4Linux
by Volkmar Uhlig 29 Oct '02

29 Oct '02

> > Just out of curiosity -- where do you want to get the not publicly > > available L4 x86-assembly kernel from to actually being > able to redo the > > measurements? It is intellectual property of a company and not > > downloadable anywhere. > I think I already have it. Otherwise, I'll make sure to contact you personally. Which won't help since I don't have it. So I'm surprised that you have an instance. > Well, I was under imperssion that L4 is highly optimized for > a processor (CPU), but not an PCI2ISA bridge or hard drive bandwidth. > Am I missing something? Please let me know, so that I don't > waste my time. So if you have a Pentium 1 and the kernel you should be fine. - Volkmar

1 0

performance of L4Linux
by Igor Shmukler 28 Oct '02

28 Oct '02

I read paper comparing performance of L4Linux of MkLinux (atop OSFMK) on x86 computer. Results are very interesting. I would really like to conduct benchmarks on my own. I know where to download Linux and L4Linux, but not the MkLinux for Intel. Does anyone still have binaries? If you do, please let me know how I could get these. Thank you, IS.

4 8

Local IPC identifier
by Jacob Gorm Hansen 25 Oct '02

25 Oct '02

hi, For some purposes when sending ipc to other threads in my task space, I find the need to explicitly state a taskid problematic. This information is redundant, and redundancy _always_ leads to problems. For me, the problem occurs when I move the l4linux server to a new task number, and another l4linux runs with my old number. All my threads get confused, and there is little I can do to help them (not without C&C at least, but that would still force me to use a taller task hierachy than I would like). What I need is something like 'if partner.id.task==0 then partner.id.task=current.id.task' in the kernel, and I suppose I will make such a hack myself. Is this what the rumoured 'lipc' feature in Pistachio is all about? Or is such a feature already present? thanks, Jacob

3 3

Lack of C&C redirection?
by Jacob Gorm Hansen 24 Oct '02

24 Oct '02

Hi, the Fiasco website says that nobody ever implemented C&C redirection for L4. Is this planned? What will happen in the current version, if I try to ipc to a task outside my clan? Best, Jacob

3 4

crt0.S and C++
by Alexey Mandrookin 15 Oct '02

15 Oct '02

Hi, Could anybody help me with crt0.S? I have project, which tightly related to L4. Project written in C++ and use abstract classes. The crt0.S was taken from FIASCO L4 examples and works well with C code. Unfortunately, it does not work with C++ code. Calling constructors for global objects does not work. Program crashed when abstract classes or virtual functions are used. It seems, virtual tables is not initialized. Guess a __static_initialization_and_destruction_0 function was not called. Does anybody have a C++ compatible crt0.S? Alexei

2 1

Native OS
by Alexey Mandrookin 09 Oct '02

09 Oct '02

Hi, does anybody interested in native OS implementation on top of a L4 microkernel? Perhaps I can donate a console driver within October. Alexei

5 7

Re: Native OS
by Frederic BOYER 09 Oct '02

09 Oct '02

I am interessed by a such project. In the past, I planed to write an Unix like on top of L4 in Ada. The goal was to port the GNAT Ada Run-Time on top of L4 and then write all the servers needed to make a good O.S. My new job take me a LOT of time, but I plan to realise this a futur day. Regards, Frédéric. "Alexey Mandrookin" <alman(a)mgateinc.com>@os.inf.tu-dresden.de on 09/10/2002 04:38:26 Sent by: l4-hackers-admin(a)os.inf.tu-dresden.de To: <l4-hackers(a)os.inf.tu-dresden.de> cc: (bcc: Frederic BOYER/PARIS/CAI-Cheuvreux) Subject: Native OS Hi, does anybody interested in native OS implementation on top of a L4 microkernel? Perhaps I can donate a console driver within October. Alexei _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers "This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Crédit Agricole Indosuez Cheuvreux except where provided for in a written agreement. Crédit Agricole Indosuez Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Crédit Agricole Indosuez Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein."

1 0