linux-kernel - Re: Re-tune x86 uaccess code for PREEMPT

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: <520712AE.6060904@zytor.com>
Date:	Sat, 10 Aug 2013 21:27:26 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Mike Galbraith <bitbucket@...ine.de>
CC:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	x86@...nel.org, mingo@...nel.org, torvalds@...ux-foundation.org
Subject: Re: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY

On 08/10/2013 09:17 PM, Mike Galbraith wrote:
>>
>> Do you have any quantification of "munches throughput?"  It seems odd
>> that it would be worse than polling for preempt all over the kernel, but
>> perhaps the additional locking is what costs.
> 
> I hadn't compared in ages, so made some fresh samples.
> 
> Q6600 3.11-rc4
> 
> vmark
> voluntary     169808     155826     154741     1.000
> preempt       149354     124016     128436      .836
> 
> That should be ~worst case, it hates preemption. 
> 
> tbench 8
> voluntary    1027.96    1028.76    1044.60     1.000
> preempt       929.06     935.01     928.64      .900
> 
> hackbench -l 10000
> voluntary     23.146     23.124     23.230     1.000
> preempt       25.065     24.633     24.789     1.071
> 
> kbuild vmlinux
> voluntary  3m44.842s  3m42.975s  3m42.954s     1.000
> preempt    3m46.141s  3m45.835s  3m45.953s     1.010
> 
> Compute load comparisons are boring 'course.
> 

I presume voluntary is indistinguishable from no preemption at all?

Either way, that is definitely a reproducible test case, so if someone
is willing to take on optimizing preemption they can use vmark as the
litmus test.  It would be really awesome if we genuinely could get the
cost of preemption down to where it just doesn't matter.

	-hpa


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