http://www.linux-kvm.org/wiki/images/4/41/KvmForum2008$kdf2008_16.pdf
On Mon, Jan 18, 2010 at 3:20 PM, David Leimbach <leim...@gmail.com> wrote: > Also, the more I think about it, the more interesting I think it is to run > different OSes in different domains on the same machines anyway. If you > want to make one thing work with another, we've got cool stuff like 9p and > v9fs to bridge gaps. > This is a very good way to force a separation of concerns between layers > anyway. L4 seems to have a way for linux processes to talk to other L4 > processes using L4 IPC when it's used for virtualization, so why not use 9P > to talk across virtualization domains? > Dave > > On Mon, Jan 18, 2010 at 3:16 PM, David Leimbach <leim...@gmail.com> wrote: >> >> Good post! Thanks for the information. I have looked at linux traces >> before and couldn't figure out why the hell so much crap was being done. >> It's as if glibc is throwing calls at the system to figure out which kernel >> it's on - another good argument for the FreeBSD model of keeping kernel and >> userspace in sync with one another. >> (typed on my fucking macbook) >> Dave >> >> On Mon, Jan 18, 2010 at 2:43 PM, <cinap_len...@gmx.de> wrote: >>> >>> i think a lot of the slowdown comes from that linux was not >>> streamlined its userspace, but the userspace just got more and more >>> complicated and does tons of redundant stuff... what they did then >>> was not to fix userspace, but they optimized the kernel to cache >>> anything... >>> >>> look at some typical syscall traces... tons of files are stat()ed... >>> multiple times... it opens unix domain sockets to talk to a not >>> existant ldap name service or something... tons of shared libraries >>> are loaded... and that is all before even your main() entry is gets >>> called... >>> >>> linuxemu doesnt shortcut these things... i cant reuse the shared >>> library mmaps on exec ect... i think walks are not cached in plan9, >>> so you have to talk to your fileserver. >>> >>> the syscall overhead is just one of the bottlenecks of linux emulation >>> and you would have to put tons of more crap in the kernel to get >>> mozilla or opera working... and even more to get it half as fast as >>> in linux. >>> >>> just keep plan9 small and simple. you dont want to maintain something >>> as complex and optimized-to-death as the full linux kernel with all >>> that caching and read aheading and 100 different stat syscalls. >>> >>> we shouldnt be araid of writing new programs and dont concentrate on >>> keeping the legacy alive so mutch. you can even run linux/major os >>> side by side with plan9 these days on virtual machines. and this gets >>> cheaper every day without doing anything. in fact this seems to be >>> what most people on iwp9 where doing. (on ther fucking macbooks) >>> >>> ;-) >>> >>> -- >>> cinap >>> >>> >>> ---------- Forwarded message ---------- >>> From: David Leimbach <leim...@gmail.com> >>> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> >>> Date: Mon, 18 Jan 2010 11:15:43 -0800 >>> Subject: [9fans] LinuxEMU >>> The SVN thread got me thinking that I had remembered seeing Ron post >>> something about what I thought was an in-kernel LinuxEMU that got a little >>> better performance on plan 9. >>> Is this true? I know the currently LinuxEMU is pretty impressive and can >>> run a large range of programs (Web browsers even!), but that sometimes the >>> performance is a little bit less than what might be desired. I believe >>> this was due to extra system call overheads for each linux kernel call. >>> Does anyone know what I'm talking about or am I just babbling away here? >>> Dave >> > >
