Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1133482ybe; Wed, 11 Sep 2019 09:53:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqz2kdJgFZPmodLr7aMv/I7wB/PX1xH7EtrG3Cme/WthIhPdFfwTuWeL30Wf1oI2dccxNoe8 X-Received: by 2002:a50:d903:: with SMTP id t3mr36648653edj.117.1568220794563; Wed, 11 Sep 2019 09:53:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568220794; cv=none; d=google.com; s=arc-20160816; b=MZ8njl0qPdnIONeairwaSoeFm9M7ucpvGmFRfGvxTikYM7dRKOAEjY8cp64YzRrLCH QZnKqRo+qFY+u/eb1os2QLCHYFNl86ZWpvqDppljykWyHvhE1xl8j7l+xJyC8gfXxybG JC+uFD2dahV9Q49e+Mr7F09QLjdV619dtxqc1XSDznrkOm/1edkNzCraCK0zaImdNhWY SMDGSdZ2Ao0UNgYrRRBRuP10fBzFziBed5YPtwfWOZP2WWHJNV1UMlEcZ3ZpMANOryHR SHFWSLP6RjLZinEFC54ULpaR56ljshS2Q9d7jqkCeHTniGSQxRiZvSy39ajUsjvQUyKP ZBxw== 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=UyBgw3AODQFVN+4HIEsd/XrS1E/piEwo3I8b+tw/RVY=; b=K5YDvnp2ouI+IZ7wMvPSHSeArXGeYu7zz4TQENADwC2pXkoQmAodECQiGLCDb/a2wO COjZQkyinif/9Wccj5XyBUhhvM+x3uXjCMslnoleC37kHfXat8wQ8yKDL07vWdtrQdIB gTJcPl2f+skMdRZoTFzElQksT98QzIwzlv73CxP4tXwHhW2C8fUujRQSWpt5MAvhimav YDdd/FqBJ18M8jy0p6/91uER+scPIC6rt6dYt4yPjtcaMksDh5ZAHrYcX0n7QI0s1LT5 nlfp/GouYCWfEGsZ/slnR9S6rYPu8IVXUxKVruUoLkNa53QC5X69k3djJpYctbygdJa0 O0tA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@digitalocean.com header.s=google header.b=EIcFZCwi; 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=REJECT sp=REJECT dis=NONE) header.from=digitalocean.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k2si14359245ede.311.2019.09.11.09.52.50; Wed, 11 Sep 2019 09:53:14 -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=@digitalocean.com header.s=google header.b=EIcFZCwi; 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=REJECT sp=REJECT dis=NONE) header.from=digitalocean.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729335AbfIKQrs (ORCPT + 99 others); Wed, 11 Sep 2019 12:47:48 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:38340 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729061AbfIKQrs (ORCPT ); Wed, 11 Sep 2019 12:47:48 -0400 Received: by mail-oi1-f194.google.com with SMTP id 7so14695561oip.5 for ; Wed, 11 Sep 2019 09:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitalocean.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UyBgw3AODQFVN+4HIEsd/XrS1E/piEwo3I8b+tw/RVY=; b=EIcFZCwiNCLKLgzI01OETGWXiJMvC3C5nUTiqtRi7Ez04rFp7Y2XUZR31V/+BVso0Y dfhQpSmWtVm7DhlL5OGmTxV+ccvXfV7MLve0lCBUILV9MyHRdqwUKevxzs/TNmvLgipA deuNb39T14E0bLyiv4cwPjNEmsxKOh6Dr+XwE= 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=UyBgw3AODQFVN+4HIEsd/XrS1E/piEwo3I8b+tw/RVY=; b=Pjj8V2fwLDOryDN1maQyXDSxuhE7JQFO14ojXfUFXhbD6HjPAzSjdHu1LHvUKyo/Bp kUuf2/dQhZVnNMflImOCPqLCaL1c2RUgevL0GHBpgTr6LWPI7ORg4zq14J5V8BQGqwVA hNuTLcYlV947Y7AjnRqM4kVlKwcRS/LYEyyBM3LZdtL5Xgmw26Q7/CaVyVyoLeQ5S36p tGDFNV8AYyAWJ4NGxvNVK6lN651XX1s9L+BbVfzX85TN3rp0mYQGyZuMsDQPxkCK9Dwr 82gYopo/nLyINRdJroHAdb1Nk6JbqC1NS91k7VZhgZkFamS6qDnTNBi/zS4cptzUTC64 +UbQ== X-Gm-Message-State: APjAAAUy8Y9AZHDnWBk0yFovSrz/pG2gEwGKrPXvtOilmKYrM60uqoD7 59Y4eNi9K9J4BHcBWli02HAn1mtp+c63sTOvZF7fng== X-Received: by 2002:aca:ab84:: with SMTP id u126mr4754572oie.115.1568220465630; Wed, 11 Sep 2019 09:47:45 -0700 (PDT) MIME-Version: 1.0 References: <20190619183302.GA6775@sinkpad> <20190718100714.GA469@aaronlu> <20190725143003.GA992@aaronlu> <20190726152101.GA27884@sinkpad> <7dc86e3c-aa3f-905f-3745-01181a3b0dac@linux.intel.com> <20190802153715.GA18075@sinkpad> <69cd9bca-da28-1d35-3913-1efefe0c1c22@linux.intel.com> <20190911140204.GA52872@aaronlu> <7b001860-05b4-4308-df0e-8b60037b8000@linux.intel.com> In-Reply-To: <7b001860-05b4-4308-df0e-8b60037b8000@linux.intel.com> From: Vineeth Remanan Pillai Date: Wed, 11 Sep 2019 12:47:34 -0400 Message-ID: Subject: Re: [RFC PATCH v3 00/16] Core scheduling v3 To: Tim Chen Cc: Aaron Lu , Julien Desfossez , Dario Faggioli , "Li, Aubrey" , Aubrey Li , Subhra Mazumdar , Nishanth Aravamudan , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Paul Turner , Linus Torvalds , Linux List Kernel Mailing , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , Kees Cook , Greg Kerr , Phil Auld , 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 > > So both of you are working on top of my 2 patches that deal with the > > fairness issue, but I had the feeling Tim's alternative patches[1] are > > simpler than mine and achieves the same result(after the force idle tag > > I think Julien's result show that my patches did not do as well as > your patches for fairness. Aubrey did some other testing with the same > conclusion. So I think keeping the forced idle time balanced is not > enough for maintaining fairness. > There are two main issues - vruntime comparison issue and the forced idle issue. coresched_idle thread patch is addressing the forced idle issue as scheduler is no longer overloading idle thread for forcing idle. If I understand correctly, Tim's patch also tries to fix the forced idle issue. On top of fixing forced idle issue, we also need to fix that vruntime comparison issue and I think thats where Aaron's patch helps. I think comparing parent's runtime also will have issues once the task group has a lot more threads with different running patterns. One example is a task group with lot of active threads and a thread with fairly less activity. So when this less active thread is competing with a thread in another group, there is a chance that it loses continuously for a while until the other group catches up on its vruntime. As discussed during LPC, probably start thinking along the lines of global vruntime or core wide vruntime to fix the vruntime comparison issue? Thanks, Vineeth