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.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 959C5C3A5A6 for ; Thu, 19 Sep 2019 15:12:09 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 629D221924 for ; Thu, 19 Sep 2019 15:12:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="aiqQrXSH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 629D221924 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4ZWg7mgvOBXR0t/gio/WClPBSwBBs7qz6Y+s/oguo1A=; b=aiqQrXSHqMu00e NPV0nLyxiGsv45KW7w+lwq8OZ8Lbpvi4ROfMUugmO4YUIbeT5Uf5yKq/+BHP6msaWLEHqgSRzdLXE VqXYGnWulivAf0uAqM5IEySMtEkoyHeurDCIojLVL54viiB+UwY53m3AVv4ROpfGPhe7mqGLhgg4L UogEQT+5d+9oAt2IHYTIuzQsrwHzMV/hBEGEJ0mrRerwNsN5esVdDp0PzYTdS7BcUyrU7T8rSD3SQ GUE0uf/k26v2JGVJQJAKpCbEUK1cHtYFBhswlckTm2qBYko0uv3NYffoQTEx1MTKCVE+u+mh21isl /Le3adtRfVmUQ0fwncDw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iAy6E-0007pE-Hl; Thu, 19 Sep 2019 15:12:02 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iAy6B-0007oV-8v; Thu, 19 Sep 2019 15:12:00 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 01E87337; Thu, 19 Sep 2019 08:11:56 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BAAF03F575; Thu, 19 Sep 2019 08:11:54 -0700 (PDT) Date: Thu, 19 Sep 2019 16:11:52 +0100 From: Qais Yousef To: Vincent Guittot Subject: Re: [PATCH 1/1] sched/rt: avoid contend with CFS task Message-ID: <20190919151152.m2zmiaspr6s5mcfh@e107158-lin.cambridge.arm.com> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190919_081159_406232_B3DCE250 X-CRM114-Status: GOOD ( 31.64 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: wsd_upstream@mediatek.com, Peter Zijlstra , linux-kernel , Jing-Ting Wu , linux-mediatek@lists.infradead.org, Matthias Brugger , Valentin Schneider , LAK Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 09/19/19 16:37, Vincent Guittot wrote: > 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 Yes possibly. But I don't think this is always doable. Especially when you're running on generic system not a special purposed one. And we don't need to favor CFS over RT. But I think they can play nicely together. For example on Android there are few RT tasks and rarely more than 1 runnable RT task at a time. But if it happened to wakeup on the same CPU that is running the UI thread you could lose a frame. And from what I've seen as well we have 1-3 CFS tasks runnable, weighted more towards 1 task. So we do have plenty of idle CPUs on average. But as I mentioned earlier I couldn't prove yet this being a serious problem. I was hoping the use case presented here is based on a real workload, but it's synthetic. So I agree we need stronger reasons, but I think conceptually we do have a conflict of interest where RT task could unnecessarily hurt the performance of CFS task. Another way to look at the problem is that the system is not partitioned correctly and the admin could do a better job to prevent this. -- Qais Yousef _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel