linux-kernel - Re: [LKP] [mm] c8c06efa8b5: -7.6% unixbench.score

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]

Date:	Tue, 27 Jan 2015 12:43:45 -0800
From:	Davidlohr Bueso <dave@...olabs.net>
To:	Huang Ying <ying.huang@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>
Cc:	LKP ML <lkp@...org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [LKP] [mm] c8c06efa8b5: -7.6% unixbench.score

On Tue, 2015-01-27 at 15:45 +0800, Huang Ying wrote:
> Hi, Davidlohr,
> 
> Any update on this?  The latest news I gotten is that you finally
> reproduced this.

The overall differences and cause of the issue is commit 37e9562453b
(locking/rwsem: Allow conservative optimistic spinning when readers have
lock). And since the performance issue occurs with writers-only, I'm
fine with the degradation,  we need to learn to live it. Real use cases
will use mutexes instead. Also, the mentioned commit fixes a much more
important problem than pathologically calling exec(2).

Now, this doesn't mean we cannot do _anything_ about it. I sent a
patcshet just a few days ago (sorry, I forgot to Cc you) that tries to
minimalize (I've recovered ~75% of the regression) the writer penalties:
https://lkml.org/lkml/2015/1/26/34

So all in all we don't really care for writer-only workloads, but hey,
while we're at it.

Thanks,
Davidlohr

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