Re: Suggestions on Avoiding syscall Overhead

From: Suleiman Souhlal <ssouhlal_at_FreeBSD.org>
Date: Wed, 25 Apr 2007 01:03:19 -0700
On Apr 23, 2007, at 4:34 AM, Jesper B. Rosenkilde wrote:

> On Sun, Apr 22, 2007 at 04:39:58PM -0700, Howard Su wrote:
>> I'd like to give some feature requests on this. I think it will not
>> increase your work load so much however it will benifit the FreeBSD a
>> lot.
>>
>> 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
>>    help on importing sysenter as syscall entry point!!
>>
>> 2. Per process Readonly page. (change will still through standard  
>> syscall)
>>    help on the syscalls:
>>    getuid, geteuid, getpid,getgid, getegid, getpgrp,
>>
>> 3. As you planed, Read+Write Page
>>
>> -- 
>> -Howard
>
> I like your suggestions a lot, I had been thinking about something  
> like the
> global page. But since I'm not that familiar with the kernel I had  
> no idea for
> what, if anything, it was useful for. I'll add your suggestions to  
> my project
> and squeeze them in my schedule.

IMHO, the main usage of the global readonly page is (apart from  
faster gettimeofday and similar) is that you can put the syscall  
entry function in it, and have the kernel choose at boot the most  
efficient method (INT 0x80 or SYSENTER/SYSCALL) based on what the CPU  
supports, while still having binaries that run everywhere.
Right now, we are forced to use INT 0x80 for syscalls, which is not  
very fast, even though most CPUs support SYSENTER/SYSCALL, because if  
we switched to these the binaries wouldn't work on older machines we  
still support.

I feel that the benefits of being able to use SYSENTER when it's  
supported would be even greater than fast gettimeofday, for most  
applications on i386 (amd64 already uses SYSCALL).
Also, doing gettimeofday through this shared page will mostly only be  
useful for machines with synchronized TSCs (assuming you want precise  
results), because otherwise you'll spend thousands of cycles just  
reading the HPET/ACPI timers anyway (you'll still save the syscall  
overhead, but it's actually smaller than the time spent reading the  
timers) (not to mention that in some cases the ACPI timer can only be  
read via an IO port).

I personally wouldn't even bother with a per-process readonly page,  
or even a R/W page: the setproctitle bug you are trying to fix is  
clearly in pgsql, and pgsql is the one that should be fixed instead  
of adding a useless and potentially complex workaround.
Similarly, I don't think getuid, geteuid, getpid,getgid, getegid,  
getpgrp are used enough to justify the work.

-- Suleiman
Received on Wed Apr 25 2007 - 06:29:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:09 UTC