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=-5.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 3EB3EC3A59F for ; Thu, 29 Aug 2019 10:38:35 +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 1489B208C2 for ; Thu, 29 Aug 2019 10:38:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="D1knv/S3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1489B208C2 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:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=feA4uXmZT+xlJAqlYYknCRG2OrqfrVqwv1nIudfjEjE=; b=D1knv/S3AmLcNY 4lOUj6A5BoCJEaz8jUsUcZd/QCjDTPu2D7YeZX08Guj/evQWvSLXhme/VWsrp3AwA7urEjbzFijQ4 VkVdqDQQ8GOhhgWxv1oZoLjolVF8E0toXzhymGoGItw3rOGcgxBef9YC6jTmxrhFkDU8mohHs0yBp KObAKdE/qbxl9PfKuBnp3bIG3NGFGqx88KMJyyjLn7fhqGwwnp46Y1OMV+ab85r/YrpSxU8WiXPyz M+CCifsMsPboJ8rys3M+mZN/ONykmbQPkeOh7/LqTkiUpt3oLkV7ESb1507qZydYta1sDKKo6v+Xo wfF5pks7nxOYBdkDN4eA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i3Hp4-0003d3-LA; Thu, 29 Aug 2019 10:38:34 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i3Hp1-0003cJ-Cy; Thu, 29 Aug 2019 10:38:32 +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 D896B360; Thu, 29 Aug 2019 03:38:28 -0700 (PDT) Received: from [10.1.194.37] (e113632-lin.cambridge.arm.com [10.1.194.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CE9F53F59C; Thu, 29 Aug 2019 03:38:27 -0700 (PDT) Subject: Re: [PATCH 1/1] sched/rt: avoid contend with CFS task To: Jing-Ting Wu , Peter Zijlstra , Matthias Brugger References: <1567048502-6064-1-git-send-email-jing-ting.wu@mediatek.com> From: Valentin Schneider Message-ID: Date: Thu, 29 Aug 2019 11:38:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <1567048502-6064-1-git-send-email-jing-ting.wu@mediatek.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190829_033831_481061_893CC25B X-CRM114-Status: GOOD ( 12.42 ) 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: linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, wsd_upstream@mediatek.com, Qais Yousef 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 29/08/2019 04:15, Jing-Ting Wu wrote: > At original linux design, RT & CFS scheduler are independent. > Current RT task placement policy will select the first cpu in > lowest_mask, even if the first CPU is running a CFS task. > This may put RT task to a running cpu and let CFS task runnable. > > So we select idle cpu in lowest_mask first to avoid preempting > CFS task. > Regarding the RT & CFS thing, that's working as intended. RT is a whole class above CFS, it shouldn't have to worry about CFS. On the other side of things, CFS does worry about RT. We have the concept of RT-pressure in the CFS scheduler, where RT tasks will reduce a CPU's capacity (see fair.c::scale_rt_capacity()). CPU capacity is looked at on CFS wakeup (see wake_cap() and find_idlest_cpu()), and the periodic load balancer tries to spread load over capacity, so it'll tend to put less things on CPUs that are also running RT tasks. If RT were to start avoiding rqs with CFS tasks, we'd end up with a nasty situation were both are avoiding each other. It's even more striking when you see that RT pressure is done with a rq-wide RT util_avg, which *doesn't* get migrated when a RT task migrates. So if you decide to move a RT task to an idle CPU "B" because CPU "A" had runnable CFS tasks, the CFS scheduler will keep seeing CPU "B" as not significantly RT-pressured while that util_avg signal ramps up, whereas it would correctly see CPU "A" as RT-pressured if the RT task previously ran there. So overall I think this is the wrong approach. > Signed-off-by: Jing-Ting Wu > --- _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel