Skip site navigation (1)Skip section navigation (2)
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>