Re: CVS commit: src/sys/kern

[David Laight <david%l8s.co.uk@localhost>]

On Sat, Jun 04, 2011 at 10:52:47AM +1000, Simon Burge wrote:
> 
> > On Thu, Jun 02, 2011 at 09:21:11PM +0100, David Laight wrote:
> > > Passing 'l' is a register rename (or copy) so is almost zero cost.
> > > 
> > > Recovering curlwp may involve a function call, and is, at best, a real
> > > memory access of global data (possibly via an asm statement) that will
> > > be slow and multiple accesses might need caching in a local anyway.
...
> As far as I could tell, the change to put curlwp in a register was never
> actually benchmarked on MIPS.  I asked a few times and never got an
> answer, other than that a kernel was about 2.5kB smaller.

Removing 2.5k is probably unlikely to make it slower :-)
Was that done by telling gcc that the register always help that variable?
or by stopping gcc using it, and useing a (non-volatile?) asm statement
to get the value.

> I'd be rather curious that if other arches investigate this, especially
> if there's some performance data to back up the change this time around.

Hmmm... I wonder if I can make it a kernel compile-time option so that
different archs can do it differently, and the whole thing can be switched
back for performance measurements.

The following defines would do it (with better names):
#ifdef SYS_CALL_USE_CURLWP
#define SYSCALL_FN(fn, l, uap, r) fn(uap, r)
#define SYSCALL_CURLWP curlwp
#else
#define SYSCALL_FN(fn, l, uap, r) fn(l, uap, r)
#define SYSCALL_CURLWP l
#endif

For non-smp builds (on old archs) 'curlwp' is a simple memory access, and the 
access
to the 'l' argument is likely to be a stack access - so probably not much 
difference.

Do we support smp vax or m68k ? (or even arm!)

IIRC the arm ABI defines standard uses for a lot of the registers, one must be 
for
thread data - so could be used in the kernel for curlwp.

Thinking about SMP, both CURCPU() and curlwp could be the register - with the
other being indirected from it.  I wonder which it used most?
curproc should be readable from either.

        David

-- 
David Laight: david%l8s.co.uk@localhost