linux-kernel - Re: spinlocks -- why are releases inlined and acquires are not?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	01 Apr 2008 13:12:09 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: spinlocks -- why are releases inlined and acquires are not?

Jiri Kosina <jkosina@...e.cz> writes:
> 
> In fact we have received report from one of our users that he is seeing 
> approximately 15% performance degradation of mmap() when spinlocks are not 
> inlined. I am going to do some performance measurements myself shortly, as 
> it seems quite strange, but while at it, I have noticed the aforementioned 
> asymetry in spinlock.h, so I just wanted to know if there is any 
> particular reason behind that.

At some point -- but that was before queued locks -- I noticed that
for i386 spin unlocks the call sequence for the sub function is
actually larger in code than the actual spin unlock operation and for
x86-64 it was about the same. That was not even counting any negative
register allocation effects the call has on the caller. Spinlocks
don't clobber a lot of registers, but the compiler doesn't know that
when calling the function so it has to assume all ABI callee clobbered
are gone.

I didn't do anything back then because at this point Ingo was
reorganizing the spinlock code hourly[1] for his lockdep etc. merge and
wanted to wait for it to settle down and then it dropped from 
the radar.

Anyways without queued spinlocks that has probably changed again,
might be still worth rechecking.

-Andi

[1] ok I'm exaggerating...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/