inlined spinlocks on sparc64

inlined spinlocks on sparc64

[Jens Axboe]

Hi,

I deleted the original thread, so I can't reply there. Just a heads up
on the spinlock inlining on sparc64. I decided to give your patches a
shot, since one of my IO benchmarks here basically degenerates into a
spinlock microbenchmark with > 50% time spent there (unlock part,
according to perf). Some of that is surely caching effects, but still.

For this particular workload, I get a net improvement of about 3.5% with
the inlined functions. Not bad.

-- 
Jens Axboe

Re: inlined spinlocks on sparc64

[David Miller]

From: Jens Axboe <jens.axboe@oracle.com>
Date: Thu, 13 Aug 2009 10:20:58 +0200

> I deleted the original thread, so I can't reply there. Just a heads up
> on the spinlock inlining on sparc64. I decided to give your patches a
> shot, since one of my IO benchmarks here basically degenerates into a
> spinlock microbenchmark with > 50% time spent there (unlock part,
> according to perf). Some of that is surely caching effects, but still.
> 
> For this particular workload, I get a net improvement of about 3.5% with
> the inlined functions. Not bad.

Doesn't surprise me, any function call can result in a register
window spill onto the stack, and that's 128 bytes of writes.

Later when you leave the code path you have to refill that spilled
window and you get 128 bytes of reads for each one of those.

Re: inlined spinlocks on sparc64

[Jens Axboe]

On Thu, Aug 13 2009, David Miller wrote:
> From: Jens Axboe <jens.axboe@oracle.com>
> Date: Thu, 13 Aug 2009 10:20:58 +0200
> 
> > I deleted the original thread, so I can't reply there. Just a heads up
> > on the spinlock inlining on sparc64. I decided to give your patches a
> > shot, since one of my IO benchmarks here basically degenerates into a
> > spinlock microbenchmark with > 50% time spent there (unlock part,
> > according to perf). Some of that is surely caching effects, but still.
> > 
> > For this particular workload, I get a net improvement of about 3.5% with
> > the inlined functions. Not bad.
> 
> Doesn't surprise me, any function call can result in a register
> window spill onto the stack, and that's 128 bytes of writes.
> 
> Later when you leave the code path you have to refill that spilled
> window and you get 128 bytes of reads for each one of those.

Good thing it's not register starved ;-)

Forgot to mention that it grew my kernel image by exactly 80KB, total
size is around 5.5MB.

-- 
Jens Axboe

Re: inlined spinlocks on sparc64

[Heiko Carstens]

On Thu, Aug 13, 2009 at 10:20:58AM +0200, Jens Axboe wrote:
> Hi,
> 
> I deleted the original thread, so I can't reply there. Just a heads up
> on the spinlock inlining on sparc64. I decided to give your patches a
> shot, since one of my IO benchmarks here basically degenerates into a
> spinlock microbenchmark with > 50% time spent there (unlock part,
> according to perf). Some of that is surely caching effects, but still.
> 
> For this particular workload, I get a net improvement of about 3.5% with
> the inlined functions. Not bad.

That sounds good! Btw. Andrew added the patches to his -mm tree, so it
looks like the patches will be merged during the next merge window.