linux-kernel - Re: inlined spinlocks on sparc64

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]

Message-Id: <20090813.020812.251047996.davem@davemloft.net>
Date:	Thu, 13 Aug 2009 02:08:12 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jens.axboe@...cle.com
Cc:	linux-kernel@...r.kernel.org, heiko.carstens@...ibm.com
Subject: Re: inlined spinlocks on sparc64

From: Jens Axboe <jens.axboe@...cle.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.
--
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/