Re: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY

[H. Peter Anvin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/