Re: [PATCH] syscall latency improvement #1

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

Andrew Morton wrote:
> > NOTE! There are potentially other ways to do all of this, _without_ losing
> > atomicity. For example, you can move the "flags" value into the slot saved
> > for the CS segment (which, modulo vm86, will always be at a constant
> > offset on the stack), and make CS=0 be the work flag. That will cause the
> > CPU to trap atomically at the "iret".
> 
> Ingo's low-latency patch put markers around the critical code section,
> and inspected the return EIP on the way back out of the interrupt.
> If it falls inside the racy region, do special stuff.

Latency tests showed that fixed the problem as well as the cli.  It's
just _much_ uglier to read, is all.

Although it saves the cli from syscalls and interrupts, it adds back a
small cost to interrupts.  Fortunately, syscall latency is far more
important than interrupt latency.

If we're going to micro-optimise the system calls, then markers are
definitely the way to fix the return path race IMHO.

-- Jamie