From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C83DBC433FF for ; Mon, 5 Aug 2019 20:09:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A19A620C01 for ; Mon, 5 Aug 2019 20:09:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730435AbfHEUJU (ORCPT ); Mon, 5 Aug 2019 16:09:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41672 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727460AbfHEUJU (ORCPT ); Mon, 5 Aug 2019 16:09:20 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2224688317; Mon, 5 Aug 2019 20:09:19 +0000 (UTC) Received: from pauld.bos.csb (dhcp-17-51.bos.redhat.com [10.18.17.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D64E1600CC; Mon, 5 Aug 2019 20:09:16 +0000 (UTC) Date: Mon, 5 Aug 2019 16:09:15 -0400 From: Phil Auld To: Julien Desfossez Cc: "Li, Aubrey" , Aaron Lu , Aubrey Li , Subhra Mazumdar , Vineeth Remanan Pillai , Nishanth Aravamudan , Peter Zijlstra , Tim Chen , Ingo Molnar , Thomas Gleixner , Paul Turner , Linus Torvalds , Linux List Kernel Mailing , =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , Kees Cook , Greg Kerr , Valentin Schneider , Mel Gorman , Pawan Gupta , Paolo Bonzini Subject: Re: [RFC PATCH v3 00/16] Core scheduling v3 Message-ID: <20190805200914.GD20173@pauld.bos.csb> References: <635c01b0-d8f3-561b-5396-10c75ed03712@oracle.com> <20190613032246.GA17752@sinkpad> <20190619183302.GA6775@sinkpad> <20190718100714.GA469@aaronlu> <20190725143003.GA992@aaronlu> <20190726152101.GA27884@sinkpad> <7dc86e3c-aa3f-905f-3745-01181a3b0dac@linux.intel.com> <20190802153715.GA18075@sinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190802153715.GA18075@sinkpad> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 05 Aug 2019 20:09:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, Aug 02, 2019 at 11:37:15AM -0400 Julien Desfossez wrote: > We tested both Aaron's and Tim's patches and here are our results. > > Test setup: > - 2 1-thread sysbench, one running the cpu benchmark, the other one the > mem benchmark > - both started at the same time > - both are pinned on the same core (2 hardware threads) > - 10 30-seconds runs > - test script: https://paste.debian.net/plainh/834cf45c > - only showing the CPU events/sec (higher is better) > - tested 4 tag configurations: > - no tag > - sysbench mem untagged, sysbench cpu tagged > - sysbench mem tagged, sysbench cpu untagged > - both tagged with a different tag > - "Alone" is the sysbench CPU running alone on the core, no tag > - "nosmt" is both sysbench pinned on the same hardware thread, no tag > - "Tim's full patchset + sched" is an experiment with Tim's patchset > combined with Aaron's "hack patch" to get rid of the remaining deep > idle cases > - In all test cases, both tasks can run simultaneously (which was not > the case without those patches), but the standard deviation is a > pretty good indicator of the fairness/consistency. > > No tag > ------ > Test Average Stdev > Alone 1306.90 0.94 > nosmt 649.95 1.44 > Aaron's full patchset: 828.15 32.45 > Aaron's first 2 patches: 832.12 36.53 > Aaron's 3rd patch alone: 864.21 3.68 > Tim's full patchset: 852.50 4.11 > Tim's full patchset + sched: 852.59 8.25 > > Sysbench mem untagged, sysbench cpu tagged > ------------------------------------------ > Test Average Stdev > Alone 1306.90 0.94 > nosmt 649.95 1.44 > Aaron's full patchset: 586.06 1.77 > Aaron's first 2 patches: 630.08 47.30 > Aaron's 3rd patch alone: 1086.65 246.54 > Tim's full patchset: 852.50 4.11 > Tim's full patchset + sched: 390.49 15.76 > > Sysbench mem tagged, sysbench cpu untagged > ------------------------------------------ > Test Average Stdev > Alone 1306.90 0.94 > nosmt 649.95 1.44 > Aaron's full patchset: 583.77 3.52 > Aaron's first 2 patches: 513.63 63.09 > Aaron's 3rd patch alone: 1171.23 3.35 > Tim's full patchset: 564.04 58.05 > Tim's full patchset + sched: 1026.16 49.43 > > Both sysbench tagged > -------------------- > Test Average Stdev > Alone 1306.90 0.94 > nosmt 649.95 1.44 > Aaron's full patchset: 582.15 3.75 > Aaron's first 2 patches: 561.07 91.61 > Aaron's 3rd patch alone: 638.49 231.06 > Tim's full patchset: 679.43 70.07 > Tim's full patchset + sched: 664.34 210.14 > Sorry if I'm missing something obvious here but with only 2 processes of interest shouldn't one tagged and one untagged be about the same as both tagged? In both cases the 2 sysbenches should not be running on the core at the same time. There will be times when oher non-related threads could share the core with the untagged one. Is that enough to account for this difference? Thanks, Phil > So in terms of fairness, Aaron's full patchset is the most consistent, but only > Tim's patchset performs better than nosmt in some conditions. > > Of course, this is one of the worst case scenario, as soon as we have > multithreaded applications on overcommitted systems, core scheduling performs > better than nosmt. > > Thanks, > > Julien --