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] [day] [month] [year] [list]

Message-ID: <20080401133053.GJ29105@one.firstfloor.org>
Date:	Tue, 1 Apr 2008 15:30:53 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: spinlocks -- why are releases inlined and acquires are not?

On Tue, Apr 01, 2008 at 02:40:49PM +0200, Jiri Kosina wrote:
> On Tue, 1 Apr 2008, Andi Kleen wrote:
> 
> > 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. 
> 
> spin unlocks seem to be properly inlined anyway, so that should be fine. 
> My concern here is the non-inlining of spin locks, for which I don't think 
> your argument above is also valid, right?

When I did the original numbers (again before queued locks) the
call was slightly shorter than the actual spin lock operation.

This was not counting register allocator effects though which
are difficult to measure generally.

-Andi
--
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/