[OpenAFS-devel] Solaris afs.rc file damage

[Dean Anderson]

On Fri, 13 Apr 2007, Tom Keiser wrote:

> On 4/12/07, Dean Anderson <dean@av8.com> wrote:
> > There may not be any degradation. The performance differences come if
> > you have to replace every syscall with an open/ioctl/close cycle.  This
> 
> I'm not concerned with open/close overhead -- the uses I'm referring
> to fall back to ioctl fd caching if syscall(AFS_SYSCALL,...) probes
> fail during application startup.

I'm not thinking of a fall-back if probes fail. The
syscall(AFS_SYSCALL...) will go away completely.  Afsd won't make these 
calls, but will make ioctls in the same place.

> What I am concerned about are call path latency differences, and far
> more importantly, locking model differences, between syscall() and
> ioctl() on our supported unix platforms.  For the project I'm working
> on, the path into the kernel module has to be lockless, and call
> latency needs to be very low, with a small jitter.

You'll have to explain this more.  The both afs_syscall and ioctl are
system calls.  The latency is the same, unless you have to make 
additional system calls, as I explained previously.

However, nearly every unix system I know of allows sched() to be called
on return through the system call trampoline, so it is unclear what it
means to be lockless or why that would be particularly important. There
are locks in the afs module. Certainly system calls have jitter as a
result of process scheduling.  This behavior isn't any different between
an ioctl and an afs_syscall---its true of every system call.

If you are trying to improve the performance of the afs kernel module,
it is usually the lock trains that kill performance---taking 6 or 10
locks to do one thing instead of one lock.  On the other hand, too few
locks are unnecessarilly blocky.  But this is all in the kernel module;  
it doesn't matter which system call you use to transfer from user mode
to kernel mode.

Whether system call latency is low or high depends on the machine
architecture. Some are quite fast. Some execute 10000+ instructions in
the trap handler on each system call, not including the purpose of the
system call.

I'm not aware of any locks taken that specific to the ioctl call that
would be taken on every ioctl call. Whether locks are necessary or taken
usually depends on the driver. We'll be providing the driver code...

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000