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

From: Andi Kleen
Date: Tue Jul 27 2004 - 10:44:11 EST


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

> On Tue, 27 Jul 2004, Andi Kleen wrote:
>
> > On Tue, 27 Jul 2004 05:29:10 -0400 (EDT)
> > Zwane Mwaikambo <zwane@xxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/