[OpenAFS-devel] .35 sec rx delay bug?

Tom Keiser tkeiser@gmail.com
Fri, 10 Nov 2006 06:01:24 -0500


On 11/10/06, Roland Kuhn <rkuhn@e18.physik.tu-muenchen.de> wrote:
> Hi Ken!
>
> On 9 Nov 2006, at 21:21, Ken Hornstein wrote:
>
> >>> Hm, I am wondering if that's a win; that means two extra syscalls.
> >>
> >> Here two extra syscalls (a few microseconds nowadays?) can save
> >> processing
> >> a packet (or more), and incurring network latency (a hundred
> >> microseconds
> >> on my Ether).
> >
> > The syscalls (context switch, a good chunk of cache getting flushed)
> > add up.  Why do you think pread() and pwrite() were created?  My point
> > was that the extra syscalls may end up killing the advantage you get
> > from sendfile() (the Linux sendfile() ... other sendfiles can add
> > in header data).  But ... that's just thinking out loud.  Maybe it
> > will be fine.
> >
> I'm not a guru, but I think that's not correct. pread/pwrite are
> there to prevent some races, not to save time. And at least in Linux

The history of pread/pwrite stretches back before preemptive
multithreading existed on unix platforms.  Syscalls weren't always
fast, and some platforms still have slow syscalls.  Even when syscalls
are fast, it's still often advantageous to coalesce multiple syscalls
which are frequently called in succession into a new complex
operation.


> syscalls are _fast_, because there is no context switch (that term is
> reserved for the switch between processes, as that is a _lot_ slower
> than entering/exiting kernel space). That's the whole point of
> mapping kernel address space into each vm (with proper protection, of
> course).
>
> A syscall is of the order of 1usec, which is much shorter than the
> network stack latencies which are being talked about in this thread.
>

I think you may be missing the point Ken was trying to make.  With
RxTCP, Ken is profiling code and trying to optimize code path
latencies.  With this type of optimization, a few microseconds can be
a huge win.  Remember that 1us latency on a modern processor means
losing on the order of 500 to ~15 thousand instruction retires.

-- 
Tom Keiser
tkeiser@gmail.com