Re: [PATCH][2.6] Allow x86_64 to reenable interrupts on contention

[Andi Kleen <ak@suse.de>]

On Tue, 27 Jul 2004 10:31:27 -0400 (EDT)
Zwane Mwaikambo <zwane@linuxpower.ca> wrote:

> On Tue, 27 Jul 2004, Andi Kleen wrote:
> 
> > On Tue, 27 Jul 2004 05:29:10 -0400 (EDT)
> > Zwane Mwaikambo <zwane@linuxpower.ca> wrote:
> >
> > > This is a follow up to the previous patches for ia64 and i386, it will
> > > allow x86_64 to reenable interrupts during contested locks depending on
> > > previous interrupt enable status. It has been runtime and compile tested
> > > on UP and 2x SMP Linux-tiny/x86_64.
> >
> > This will likely increase code size. Do you have numbers by how much? And is it
> > really worth it?
> 
> Yes there is a growth;
> 
>    text    data     bss     dec     hex filename
> 3655358 1340511  486128 5481997  53a60d vmlinux-after
> 3648445 1340511  486128 5475084  538b0c vmlinux-before

That's significant.

> 
> And this was on i386;
> 
>    text    data     bss     dec     hex filename
> 2628024  921731       0 3549755  362a3b vmlinux-after
> 2621369  921731       0 3543100  36103c vmlinux-before
> 
> Keith Owens managed to get increased throughput as the original patch was
> driven by poor performance from a workload. I think it's worth it just for

What workload was that?

I am not sure it is a good idea to "fix" workloads by making spinlocks better.
It is likely better to just fix the locking for that workload, that would
likely improve the workload a lot more.

> the reduced interrupt latency, the code size issue can also be taken care
> of, but that requires benchmarking as the change is a bit more drastic.

Do you have numbers on that? Frankly if someone is spinning on irq disabled
locks for a long time they should just fix their code.

-Andi