From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <3e1162e61001181115i388b528el57bcf22629c748f9@mail.gmail.com> Date: Mon, 18 Jan 2010 15:16:41 -0800 Message-ID: <3e1162e61001181516x31367cceqb8786cc072cdfec8@mail.gmail.com> From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cdf0fa2cf6bbf047d788b30 Subject: Re: [9fans] LinuxEMU Topicbox-Message-UUID: c0884f16-ead5-11e9-9d60-3106f5b1d025 --000e0cdf0fa2cf6bbf047d788b30 Content-Type: text/plain; charset=ISO-8859-1 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, 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 > 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 > > --000e0cdf0fa2cf6bbf047d788b30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good post! =A0Thanks for the information. =A0I have looked at linux traces = before and couldn't figure out why the hell so much crap was being done= . =A0It's as if glibc is throwing calls at the system to figure out whi= ch kernel it's on - another good argument for the FreeBSD model of keep= ing kernel and userspace in sync with one another.

(typed on my fucking macbook)

Dave<= br>
On Mon, Jan 18, 2010 at 2:43 PM, <cinap_lenrek@gmx.de> wrote:
i think a lot of the slowdown comes from th= at linux was not
streamlined its userspace, but the userspace just got more and more
complicated and does tons of redundant stuff... =A0what they did then
was not to fix userspace, but they optimized the kernel to cache
anything...

look at some typical syscall traces... =A0tons of files are stat()ed...
multiple times... =A0it opens unix domain sockets to talk to a not
existant ldap name service or something... =A0tons of shared libraries
are loaded... =A0and that is all before even your main() entry is gets
called...

linuxemu doesnt shortcut these things... =A0i cant reuse the shared
library mmaps on exec ect... =A0i 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... =A0and even more to get it half as fast as
in linux.

just keep plan9 small and simple. =A0you 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. =A0you can even run linux/major os
side by side with plan9 these days on virtual machines. =A0and this gets cheaper every day without doing anything. =A0in fact this seems to be
what most people on iwp9 where doing. =A0(on ther fucking macbooks)

;-)

--
cinap


---------- Forwarded message ----------
From:=A0David Lei= mbach <leimy2k@gmail.com>To:=A0Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date:=A0Mon, 18 Jan 2010 11:15:43 -0800
Subject:=A0[9fans] LinuxEMU
T= he SVN thread got me thinking that I had remembered seeing Ron post somethi= ng about what I thought was an in-kernel LinuxEMU that got a little better = performance on plan 9.

Is this true? =A0I know the currently LinuxEMU is pretty imp= ressive and can run a large range of programs (Web browsers even!), but tha= t sometimes the performance is a little bit less than what might be desired= . =A0 I believe this was due to extra system call overheads for each linux = kernel call. =A0

Does anyone know what I'm talking about or am I jus= t babbling away here?

Dave


--000e0cdf0fa2cf6bbf047d788b30--