From mboxrd@z Thu Jan 1 00:00:00 1970 From: dexen deVries To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Date: Fri, 18 Feb 2011 17:53:29 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.38-rc4-19+; KDE/4.5.5; x86_64; ; ) References: <201102181445.41877.dexen.devries@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201102181753.30125.dexen.devries@gmail.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b07a1d74-ead6-11e9-9d60-3106f5b1d025 On Friday, February 18, 2011 04:15:10 pm you wrote: > Benchmark utilities to measure the overhead of syscalls. It's cheating > to do for getpid, but for other things like gettimeofday, it's > *extremely* nice. Linux's gettimeofday(2) beats the socks off of the > rest of the time implementations. About the only faster thing is to > get CPU speed and use rdtsc. Certainly no other OS allows you to get > the timestamp faster with a syscall. Would you mind explaining what technique is used by Linux to speed up the=20 gettimeofday()? I'd guess it's not per-process caching... and if it's not,= =20 then it involves two context-switches; not the fastest thing in my books. As for performance in general, some speculative fiction: in general, drivers are kept in kernel for two reasons -- to protect resour= ces=20 from processes going rogue and to provide common, infrequently changing API= to=20 diverse hardware. The later reason is pretty much security-insensitive and= =20 serves to aid cross-platform development. In principle, the read-only parts of some drivers could be embedded in=20 processes (things like system timer, rather than harddrive). Is there any O= S=20 out there that actually lets processes embed the read-only parts of drivers= to=20 avoid context switches for going through kernel? The closest thing I can think of is Google's Native Client, which lets=20 untrusted code execute (within a trusted `host process') with constrained,= =20 readexecute-only access to trusted code so it can execute hand-picked sysca= lls=20 & communication with the host process. Perhaps a *constrained* read-write driver for harddrive (and filesystem) ac= cess=20 could perhaps also be held rx-only in virtual memory of untrusted code... =2D-=20 dexen deVries [[[=E2=86=93][=E2=86=92]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90