Received: by 2002:a25:b323:0:0:0:0:0 with SMTP id l35csp27691ybj; Thu, 19 Sep 2019 10:08:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqwoTtXHc8A1GE6IhB6ZLD30bM8BCO8QD08xT66sNEJeYgQAwtFKQ5+gN9wYgTc3RlVt1P9B X-Received: by 2002:aa7:c897:: with SMTP id p23mr13915272eds.199.1568912901424; Thu, 19 Sep 2019 10:08:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568912901; cv=none; d=google.com; s=arc-20160816; b=Ej9qzFGDUGybK0pqY2szh3K6RwHDsNsG2OQOx8VNFcqEYRj/LeSGoC0152TpQbyuwT qzoZmSVn3drkf1fqGm9xhbRl8imN4nWNuh+6AoS+G7aLsnOZju2ZGiLc98RIA2PrwNLM PgSsEdlAmplGhWIHxiJ9inRFJ8cIKuvJ0Za6NzOswIU0yHQ+yZGge5A+ZiQMuxpovZvA g1gul3u7+qzLk1nBDXJmbTGG1d6YHtPexcVxcDac4qQgIn3AJdWochJF+I/5Y+8+obnw kM+Ml2UneCtL4XGN0CYo+JWLyKfq/Y7e913X3bNyzWoU6Zo+RfuwIdKJFY16iuVUY1+Q IXEw== 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=C/YKIIlDS8lZho9e4vPUeHyogrERU8xcKbZimBkWeCQ=; b=XZF/St5+0a+yVJXjSHN3vGJcRvQLSxktScvACulx5Kgk59r4zeaRAG1cKAYXZlmF93 bKMlfjllRDfy0x6Qfzo5QjLhQRIdNMNo0oAjcIpfYBpFFvcPZbgFdeQzN9KBo0nY2bcg biplMdzdNxqOSaJs5YkczXVq5vCV70nv4SGkVpSFkOFZuyrur2VVSUXYaocNuXJpapbY s6uVLSTOTNyEAJTBQIKHBOecb4Br42UITaL6Ra8nhuQ08yySm6ZnzzT2y46NqOTUGGpH czdhVeUw0xHQj0c/onMh8O+2YthAkb435clVfrxh9zFAaD35XvJAuYde9RGhBeVnL7ma BWHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=W3UQB2Rr; 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=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p14si6357952eda.411.2019.09.19.10.07.58; Thu, 19 Sep 2019 10:08:21 -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=@linaro.org header.s=google header.b=W3UQB2Rr; 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=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732617AbfISOhY (ORCPT + 99 others); Thu, 19 Sep 2019 10:37:24 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:35644 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731857AbfISOhX (ORCPT ); Thu, 19 Sep 2019 10:37:23 -0400 Received: by mail-lf1-f65.google.com with SMTP id w6so2564198lfl.2 for ; Thu, 19 Sep 2019 07:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C/YKIIlDS8lZho9e4vPUeHyogrERU8xcKbZimBkWeCQ=; b=W3UQB2RrUJ6vv2M8HVuZVtFpnWXhc3dHhXFwnUsp6CeKd30GsXdyZZw2GFh1mxC8km vK8dfFCRgbYvp6PeqcgtD7al/L9UpnvwUFuj5EeKyCb0WOfA7CScYIPAbsF4N2ksXz+0 X4t+cFR8bz6VRAnE7V77kNi4ZdoCg+MnmI+sUsyRi/1LTugIZgMwa2ClGlOWdvcHoaH8 +ciin3FlYbQS3Fy5VogrE4bthJuZjKAoBoA6slyjZ0Dw8KKNftfxZzE7oEjyQLr1T74z CqgGfFvOg0nHEtuAYtO/wcP+KA/k+Vxl4lkpGrA4E9ZKdgyxFQShtZE6p9OLLMFcHNy7 09og== 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=C/YKIIlDS8lZho9e4vPUeHyogrERU8xcKbZimBkWeCQ=; b=hQB5ih9appRsmBpY/m70ChMTnvDtUwqAiznPCy0pIRIqwrR6Kv38jbaDgMjqEonWFH DTMxU56BxO+2LVf7E4wO8LGajsUBj4wmPAHGpRLsWFFRzetD/VV4cMWdygL/0wUa1mby npGp0AeEsugmU946cz3r4dwx/zsAK+/LQqvJqz052FtDZm0h1Egh5azsY6L8jALCiZDa lgWMzhrWplg/o7yD4uPn5W/OeGGE+ojM3GEo9+wFuicS9d/zPhYrw02qn7i3w7OAKUcK /z3GvuGNeMAnjmcyTGZCah6XbSn3qr8v2nxVKowOgyxiQV31DdLdQ+vbws+cOrHWRwPy 07NQ== X-Gm-Message-State: APjAAAXasIptrgnKfsDdpEYmAgir7hoD2bfBByt/AFmhd99n9XMFHiQy g5V7xFO9P5ixeZlxZGFjiROohRKAEpIDtHO+DhQU0A== X-Received: by 2002:ac2:568c:: with SMTP id 12mr5126705lfr.133.1568903841835; Thu, 19 Sep 2019 07:37:21 -0700 (PDT) MIME-Version: 1.0 References: <1567048502-6064-1-git-send-email-jing-ting.wu@mediatek.com> <20190830145501.zadfv2ffuu7j46ft@e107158-lin.cambridge.arm.com> <1567689999.2389.5.camel@mtkswgap22> <1568892135.4892.10.camel@mtkswgap22> <20190919142315.vmrrpvljpspqpurp@e107158-lin.cambridge.arm.com> In-Reply-To: From: Vincent Guittot Date: Thu, 19 Sep 2019 16:37:10 +0200 Message-ID: Subject: Re: [PATCH 1/1] sched/rt: avoid contend with CFS task To: Qais Yousef Cc: Jing-Ting Wu , Valentin Schneider , Peter Zijlstra , Matthias Brugger , wsd_upstream@mediatek.com, linux-kernel , LAK , linux-mediatek@lists.infradead.org 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, 19 Sep 2019 at 16:32, Vincent Guittot wrote: > > On Thu, 19 Sep 2019 at 16:23, Qais Yousef wrote: > > > > On 09/19/19 14:27, Vincent Guittot wrote: > > > > > > But for requirement of performance, I think it is better to differentiate between idle CPU and CPU has CFS task. > > > > > > > > > > > > For example, we use rt-app to evaluate runnable time on non-patched environment. > > > > > > There are (NR_CPUS-1) heavy CFS tasks and 1 RT Task. When a CFS task is running, the RT task wakes up and choose the same CPU. > > > > > > The CFS task will be preempted and keep runnable until it is migrated to another cpu by load balance. > > > > > > But load balance is not triggered immediately, it will be triggered until timer tick hits with some condition satisfied(ex. rq->next_balance). > > > > > > > > > > Yes you will have to wait for the next tick that will trigger an idle > > > > > load balance because you have an idle cpu and 2 runnable tack (1 RT + > > > > > 1CFS) on the same CPU. But you should not wait for more than 1 tick > > > > > > > > > > The current load_balance doesn't handle correctly the situation of 1 > > > > > CFS and 1 RT task on same CPU while 1 CPU is idle. There is a rework > > > > > of the load_balance that is under review on the mailing list that > > > > > fixes this problem and your CFS task should migrate to the idle CPU > > > > > faster than now > > > > > > > > > > > > > Period load balance should be triggered when current jiffies is behind > > > > rq->next_balance, but rq->next_balance is not often exactly the same > > > > with next tick. > > > > If cpu_busy, interval = sd->balance_interval * sd->busy_factor, and > > > > > > But if there is an idle CPU on the system, the next idle load balance > > > should apply shortly because the busy_factor is not used for this CPU > > > which is not busy. > > > In this case, the next_balance interval is sd_weight which is probably > > > 4ms at cluster level and 8ms at system level in your case. This means > > > between 1 and 2 ticks > > > > But if the CFS task we're preempting was latency sensitive - this 1 or 2 tick > > is too late of a recovery. > > > > So while it's good we recover, but a preventative approach would be useful too. > > Just saying :-) I'm still not sure if this is the best longer term approach. > > like using a rt task ? I mean, RT task should select a sub optimal CPU because of CFS If you want to favor CFS compared to RT it's probably because your task should be RT too > > > > > -- > > Qais Yousef