Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp94772yba; Wed, 8 May 2019 17:03:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqyUd1iiXUIImj/f4Y1mH4K5RihcaSjHQDEMVEH5I1CUf2hs3Qq9EAgJDMgscBltA0xI5/gQ X-Received: by 2002:a17:902:b095:: with SMTP id p21mr905189plr.40.1557360233681; Wed, 08 May 2019 17:03:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557360233; cv=none; d=google.com; s=arc-20160816; b=UOGYO8R13AM7solYs9ahV2BzdlZoLSn1QiXpUY5SG2Eo2CKl+ypYrEiXG/vXc9w74C 54/d/hMvWNCJhl4CRzvLc78DTZuojpqVDlNkdtRpNcKVLm9C6HR9mnXgTuMbJI+wPhnZ K89Jsq022IqowQEkCeOAZPSQ8BoL6nDE5xj2tSvuKvGrViQXtxjgdLaYxsisFtEkr+KQ Z5lwiBqt0jktRDe/C6vpNW/q2aLppZ27VOYA/DrCcljavezjmekFDadONdp641sbpanE F7JdVliARhiMU5Z80D1WF4A+hqC5q+rg+XwtF9pTd4mm2ALGb3JZRuXhIT7KbQs1rotQ z6dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=GB8jreGg4VZYtPBoB9kcqZSYlkH1FrXZGlEq5Cw8HWE=; b=qGNj81vzgWa2ieG35hq0tNLYXnnS4u8QHJ9A6GlArsH0O2qFLN7pVUECPna/sADIA/ XxpPCjyO4HbpOXnKXSP24vBZkjEvWnZSwJE8EdFzqGwPv+PHx3n5I7ONWgk0o0bWfJat zZbBNQlF75pAku4QeEUL5Vb1Qt6ImU0s+vWvoyCzQycE2+re2e4pzuPAG+OETj5LYu0e oESkUQJn4vuB3bJCKQ52sI3mTZg96kEU1uLVeFwOchll1hKzo6PzjE4poqKEOyFlzMlT WTJUBaintj7hBnQnAmQz7gUWKY+jM1XHOhIwUHVIJqMXKlIbJsPsj0Z3mREqkRwLG6ac dVmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EWHSQ88l; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c25si362609pfr.94.2019.05.08.17.03.37; Wed, 08 May 2019 17:03:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EWHSQ88l; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727673AbfEIABp (ORCPT + 99 others); Wed, 8 May 2019 20:01:45 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:38668 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726506AbfEIABp (ORCPT ); Wed, 8 May 2019 20:01:45 -0400 Received: by mail-lj1-f193.google.com with SMTP id 14so422688ljj.5 for ; Wed, 08 May 2019 17:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GB8jreGg4VZYtPBoB9kcqZSYlkH1FrXZGlEq5Cw8HWE=; b=EWHSQ88l4pmf8aYlogAQdLJyoQx2530eBeKC3U703BVfeSQBlhbSEQ0ZAa3yfIj+DH VtKVIc2aNHUph9IK1GAVp68kFLna8GmL8IXYwqOl5GFGKeV2Ynd1hDWB2V/6u7/H94Jb mwH3K7zeNzWa2/Dpl6K/oOvh8WyhLSPZ1t7IZ3UcP8vdudx+VCbn/s/WY/6YIa5HGOeJ LdqqzPV2txK58TdxQJuUF5/HVXyj1WJp9Z1WEsycFwKNdUN32ohhTrsojvRGABaMt0fm P5facCvhsEeQPIOy9Pio2tcPcAauRZUA5Hx2QOHYwsQXSanYXzXTWO9Q3bE5Kf+8jQtU Kt7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GB8jreGg4VZYtPBoB9kcqZSYlkH1FrXZGlEq5Cw8HWE=; b=C1Mpr3009QpFFhr2iZ4nQDALLTMpckm4kJXVs4DxyYd5toqk3zyFquzhKb/5ea+bua CTlaNI64o8dgBHp9rrGlDhTpOfqN+p2ldWqvRdKsU4n78Z3PhFfUj5MTSC5kkIjfeupo jT2a4tIiwRo8YmRo8LeZ+MtQJeVb0NwP3YOlkhTyQ/EAlZgxkRtIXZ8BpYq13Pepozq7 AZeMGVSLbr923jeEkCVz31m6nH/zmCb7MuQLqZDUwBv3NxlxC6wAp8FH9nF6nyNmZxr/ aWzkdzcNVMeUOZBa5Tk5ilY4m0eapWZEWzxVgc/AJrQjagu6SlQuRcJQRoPcmu9Tqr5C b4Aw== X-Gm-Message-State: APjAAAXiwxE8UEkYc/YH1yd6oXOs9QNLWWV0S57LyXSoMoiBQtkDxUOB 1e0UEEsPVYGvT1uIR1iQjtSQmLFc6zwmm/8F7I0= X-Received: by 2002:a2e:984d:: with SMTP id e13mr347470ljj.61.1557360103300; Wed, 08 May 2019 17:01:43 -0700 (PDT) MIME-Version: 1.0 References: <2364f2b65bf50826d881c84d7634b6565dfee527.1556025155.git.vpillai@digitalocean.com> <20190429061516.GA9796@aaronlu> <6dfc392f-e24b-e641-2f7d-f336a90415fa@linux.intel.com> <777b7674-4811-dac4-17df-29bd028d6b26@linux.intel.com> <28fb6854-2772-5d29-087a-6a0cf6afe626@oracle.com> In-Reply-To: <28fb6854-2772-5d29-087a-6a0cf6afe626@oracle.com> From: Aubrey Li Date: Thu, 9 May 2019 08:01:31 +0800 Message-ID: Subject: Re: [RFC PATCH v2 11/17] sched: Basic tracking of matching tasks To: Subhra Mazumdar Cc: Tim Chen , Aaron Lu , Vineeth Remanan Pillai , Nishanth Aravamudan , Julien Desfossez , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Paul Turner , Linus Torvalds , Linux List Kernel Mailing , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , Kees Cook , Greg Kerr , Phil Auld , Aaron Lu , Valentin Schneider , Mel Gorman , Pawan Gupta , Paolo Bonzini Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 9, 2019 at 2:41 AM Subhra Mazumdar wrote: > > > On 5/8/19 11:19 AM, Subhra Mazumdar wrote: > > > > On 5/8/19 8:49 AM, Aubrey Li wrote: > >>> Pawan ran an experiment setting up 2 VMs, with one VM doing a > >>> parallel kernel build and one VM doing sysbench, > >>> limiting both VMs to run on 16 cpu threads (8 physical cores), with > >>> 8 vcpu for each VM. > >>> Making the fix did improve kernel build time by 7%. > >> I'm gonna agree with the patch below, but just wonder if the testing > >> result is consistent, > >> as I didn't see any improvement in my testing environment. > >> > >> IIUC, from the code behavior, especially for 2 VMs case(only 2 > >> different cookies), the > >> per-rq rb tree unlikely has nodes with different cookies, that is, all > >> the nodes on this > >> tree should have the same cookie, so: > >> - if the parameter cookie is equal to the rb tree cookie, we meet a > >> match and go the > >> third branch > >> - else, no matter we go left or right, we can't find a match, and > >> we'll return idle thread > >> finally. > >> > >> Please correct me if I was wrong. > >> > >> Thanks, > >> -Aubrey > > This is searching in the per core rb tree (rq->core_tree) which can have > > 2 different cookies. But having said that, even I didn't see any > > improvement with the patch for my DB test case. But logically it is > > correct. > > > Ah, my bad. It is per rq. But still can have 2 different cookies. Not sure > why you think it is unlikely? Yeah, I meant 2 different cookies on the system, but unlikely 2 different cookies on one same rq. If I read the source correctly, for the sched_core_balance path, when try to steal cookie from another CPU, sched_core_find() uses dst's cookie to search if there is a cookie match in src's rq, and sched_core_find() returns idle or matched task, and later put this matched task onto dst's rq (activate_task() in sched_core_find()). At this moment, the nodes on the rq's rb tree should have same cookies. Thanks, -Aubrey