9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: cinap_lenrek@gmx.de
To: 9fans@9fans.net
Subject: Re: [9fans] LinuxEMU
Date: Mon, 18 Jan 2010 23:43:20 +0100	[thread overview]
Message-ID: <bae4234029d10f74f53b01999253e70d@gmx.de> (raw)
In-Reply-To: <3e1162e61001181115i388b528el57bcf22629c748f9@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

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

[-- Attachment #2: Type: message/rfc822, Size: 4471 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 561 bytes --]

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

[-- Attachment #2.1.2: Type: text/html, Size: 630 bytes --]

  parent reply	other threads:[~2010-01-18 22:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-18 19:15 David Leimbach
2010-01-18 20:01 ` ron minnich
2010-01-18 20:11   ` David Leimbach
2010-01-18 20:23     ` ron minnich
2010-01-18 22:43 ` cinap_lenrek [this message]
2010-01-18 23:16   ` David Leimbach
2010-01-18 23:20     ` David Leimbach
2010-01-18 23:46       ` Eric Van Hensbergen
2010-01-27 14:42   ` Ethan Grammatikidis
2010-02-06  1:08   ` Enrico Weigelt
2010-02-06 17:56     ` cinap_lenrek
2010-02-06 18:26       ` David Leimbach
  -- strict thread matches above, loose matches on Subject: below --
2003-02-11 11:19 [9fans] Linuxemu peter a. cejchan
2002-11-28 16:33 Russ Cox
2002-11-28  8:17 Petr Cejchan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bae4234029d10f74f53b01999253e70d@gmx.de \
    --to=cinap_lenrek@gmx.de \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).