From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751200AbdIOEH3 (ORCPT ); Fri, 15 Sep 2017 00:07:29 -0400 Received: from mout.gmx.net ([212.227.15.18]:50019 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751169AbdIOEH1 (ORCPT ); Fri, 15 Sep 2017 00:07:27 -0400 Message-ID: <1505448381.10814.64.camel@gmx.de> Subject: Re: [lkp-robot] [sched/fair] 6d46bd3d97: netperf.Throughput_tps -11.3% regression From: Mike Galbraith To: Rik van Riel , Joel Fernandes Cc: kernel test robot , LKML , Peter Zijlstra , Josef Bacik , Juri Lelli , Brendan Jackman , Dietmar Eggemann , Matt Fleming , Ingo Molnar , lkp@01.org Date: Fri, 15 Sep 2017 06:06:21 +0200 In-Reply-To: <1505404603.12821.19.camel@redhat.com> References: <20170827010226.19703-1-joelaf@google.com> <20170910134021.GB29265@yexl-desktop> <1505098524.18240.42.camel@gmx.de> <1505404603.12821.19.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:u75DX0uJg/u6BwKuV8RAK7zJf7TI1TgpvW26/HV4QB/q7e174P3 Ow6Gsecm0RuBwwCscm9RIE0OhHEbN6WNA4cVo9mxugpcXIp5rC3ifr2axscuR4hgR6c1F3z bi6IHcdK3byRJOP4SJrZVob3KCbQ65XT4VNuJhi3fcsDvsZ/CzsoTuMHZoDz/dXqODWaVAf iFDUE7EdEpMrLi+Le+K0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:UF5J+DpPyZU=:h9H6MCfKLZ7CpXxNZj7T4Q 8rYTz5qZ53BswPr4bYEdzt7X2BpOzLLiMk04MRDtR2oRUoGDPMkOLxyACZRNspggg61uRqb2G fWom667jApTTy7HNOAnxXPDowFdDAvCNAeDCB31VsbJp2RZ9n+9DwmXOw33VoVA3lvWVlASa4 R30B+6/yBzKgjnXDoN345VqS9KdMQh6Sts9Scu5LVs73tWohcXtxOA1YNDNwSYJhJCPNsRrbg eeuw2TQdv0+iL/CHYdvi4fjx6eN0FZJEsJHitgmpu03bA87PlHgJl8w3cb/mHHsjiGSEB0rgd 2Wly21p3igcMDzlLV4+XA7LPoju8CRtKExalc6xu/0HbFGd4fPJTiYdhIp7upIkZ4sMRb6dNu mNwk/CtQmn5fMP5VhQ3ZYBdP8Ywsl4f+kGFH6kW5RxMQxp8t7itlqTv67tM9ERwXZDJNa3PCk MDEmb4XoR5EC7f4y10vkV+m0xdPpK0FxF8LYQhoMQOhvtYQMpyoKa5s8hZxZYEJej9gPsl0uM jseTbZ9wD+vvAvE7B4EtfsnSiZV+Wa66P0cuOmLqYyNikGwKHAX+YJ0OKKWPo9QgGabNRdfap wQXYpmWf4kAoY40BndI7zaGNwFMe4+Dy0zUc80sdPbThz1CcUXXVobn7vZylBqJlD2sW+0STO dRJeXnijgPOUWgzGVw6zYSUK8FzT8g06NqSS+cFwWJgg1U6c9GkdUexbao6c600h4g1fWY2kH lRspHdISFk7WKS5A6CBSBG+LLU3oc6B0zHBepwbFTUFAu9MuwmhE9SDUdX5+hT/Idz9RgDaSa hLp/X/12Nw6S5ikmyO70yAdJuMEQBwvjcWxa274SqVtYQvenpY= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-09-14 at 11:56 -0400, Rik van Riel wrote: > > On systems with SMT, it may make more sense for > sync wakeups to look for idle threads of the same > core, than to have the woken task end up on the > same thread, and wait for the current task to stop > running. Depends. homer:/root # taskset -c 3 pipe-test 1.412185 usecs/loop -- avg 1.412185 1416.2 KHz homer:/root # taskset -c 2,3 pipe-test 2.298820 usecs/loop -- avg 2.298820 870.0 KHz homer:/root # taskset -c 3,7 pipe-test 1.899164 usecs/loop -- avg 1.899164 1053.1 KHz For pipe-test, having ~zero overlap as well as ~zero footprint, that's a good choice, but.. homer:/root # taskset -c 3 tbench.sh 1 10 2>&1|grep Throughput Throughput 844.04 MB/sec 1 clients 1 procs max_latency=0.042 ms homer:/root # taskset -c 2,3 tbench.sh 1 10 2>&1|grep Throughput Throughput 713.25 MB/sec 1 clients 1 procs max_latency=0.324 ms homer:/root # taskset -c 3,7 tbench.sh 1 10 2>&1|grep Throughput Throughput 512.866 MB/sec 1 clients 1 procs max_latency=0.454 ms ..for tbench, where my crusty ole Q6600 turns in a win by scheduling the pair on separate L2 sharing cores, for the more modern SMT equipped i4790, targeting shared L2 is the worst choice. Bigger issue is that while microbenchmark behavior is consistant, applications tend to process data and react to it (vs merely batting it about like playful kittens, cute, but not all that productive), likely mucking up any heuristic anyone invents with depressing regularity. -Mike