lkml.org 
[lkml]   [2013]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY
From
Date
On Sat, 2013-08-10 at 21:27 -0700, H. Peter Anvin wrote: 
> 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?

No, all preemption options produce performance deltas.

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

You have to eat more scheduler cycles, that's what PREEMPT does for a
living. Release a lock, wham.

-Mike



\
 
 \ /
  Last update: 2013-08-11 07:01    [W:0.073 / U:1.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site