Date: Mon, 23 Apr 2007 21:05:51 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Maxime Henrion <mux@freebsd.org> Cc: current@freebsd.org, "Jesper B. Rosenkilde" <jbr@humppa.dk> Subject: Re: Suggestions on Avoiding syscall Overhead Message-ID: <462D821F.6030707@freebsd.org> In-Reply-To: <20070423161711.GV39474@elvis.mu.org> References: <f126fae00704221639l68095de1ye7ce9ba3d921bf20@mail.gmail.com> <20070423113400.GC28587@gw.humppa.dk> <462CD251.9060105@freebsd.org> <20070423161711.GV39474@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>We can have 3 type of pages mapped into one process's address map. >>>>1. System wide global readonly page which will help on these syscalls: >>>> gethostname,getdomainname,uname >>>>2. Per process Readonly page. (change will still through standard syscall) >>>> help on the syscalls: >>>> getuid, geteuid, getpid,getgid, getegid, getpgrp, >> >>I don't really understand this suggestion. >>Do any real programs call these syscalls very often? > > There is indeed more and more programs calling some syscalls a > *lot* .... MySQL calls gettimeofday() so much that changing > the timer used on a system can lead to a very observable performance > improvement. Similarly, PostgreSQL calls setproctitle() a lot ... Accelerating gettimeofday() makes a lot of sense; I've seen a lot of programs that call it very often. I'm not convinced about calls such as getuid() and gethostname(), though. Putting this kind of information in userspace introduces forward-compatibility concerns. People do statically link against libc, so you have to make sure that libc can find this information even when running on future kernels. That makes each such call a tricky maintenance issue. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?462D821F.6030707>