"Igor Shmukler" <[EMAIL PROTECTED]> writes: > First, I'd like to note that my domain apparently been compromised > and Jean's server bounces it, which makes replying a little more > difficult than it could be.
The mailinglist is subscriber only so simply subscribe to it and ou problems go away. > In previous email Jean suggested to check string to ensure that I > have correct kernel version. Which I will do once I get around to > it. To be honest this raises a question. If I in fact have wrong > kernel version, could I get that particular one? 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) > I also think that for tests to make sense I'd need compiler version > and arguments passed to it. I don't think that explanation on > purpose of that is needed. Standard Linux makefile options, L4Linux used 4 Mb pages and small address spaces (there where some config options but I think they are set in the makefile) > > > Well obvious solution to Mach's problems is critical path optimizations. > > wow, /me wonders why no-one ever thought about that... > Fact that people thought about it, does not mean that it has been > done and/or ineffective. No comment... > > > Well, I was talking about "First class flexpage-based address > > > spaces" paper presented in by Shapiro in(around) 2000. > > > > (Unfortunatly I was only able to browse the text version provided by > > google since the Server providing the post script version is down) > I am attaching paper to the message. Don't know if mailing list > server will not strip it. - read 4.1 and try to implement a non trivial pager like the linux server. 16 slots (16 Mappings) per address space and a pager which uses single pages to resolve page faults (and therefore needs on slot per page) doesn't seem to work very well. - Adress space construction becomes a complicated operation (do I have enough slots or do I have to use two adress spaces or even more to construct the real adress space) - what about recursive address space construction? How do I remove mappings created by another process based on the mapppings I gave it? Thats the whole reason for the mapping tree Shapiro is complaining about. And I don't see how this situation is handled by his proposed solution. - Shapiro tries to remove the mapping database but introduces capabilities into the kernel, which are dynamically created and have to be managed somehow There are other proposals which handle the resource allocation problem in a better way... Regards, Jean _______________________________________________ l4-hackers mailing list [EMAIL PROTECTED] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
