* Rik van Riel <r...@redhat.com> wrote:
> On 08/07/2014 06:53 AM, Fengguang Wu wrote:
> > Hi Rik,
> >
> > We noticed the below performance regression in commit
> > 096aa33863a5e48de52d2ff30e0801b7487944f4 ("sched/numa: Decay
> > ->wakee_flips instead of zeroing")
> >
> > b1ad065e65f5610 096aa33863a5e48de52d2ff30 testbox/testcase/testparams
> > --------------- ------------------------- ---------------------------
> > 122361 ± 0% -21.4% 96140 ± 0%
> > lkp-snb01/hackbench/50%-process-pipe
> > 122361 ± 0% -21.4% 96140 ± 0% TOTAL hackbench.throughput
>
> I guess the performance of that benchmark depends on it
> "slipping under the wire" after each time the kernel
> zeroes out ->wakee_flips.
>
> Depending on repeatedly pulling the wakee back to the same
> node as the waker suggests something else in the kernel may
> be pulling the wakee to another place in the system repeatedly,
> as well, just at a lower frequency (load balancer?).
>
> I have also noticed that select_idle_sibling often fails to
> find an idle sibling within the LLC domain, even when it
> exists. Fixing that bug sometimes results in lower performance.
>
> It appears that some of the performance results of the scheduler
> appear on the code acting in an opposite way to its documented
> intention.
>
> It may be best to revert 096aa33863a for now...
Mind sending a revert patch, with an explanation, a Reported-by, etc?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
