Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2513528ybt; Tue, 16 Jun 2020 08:01:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyn2fyvHQAMMBeZ3/d8/ga1CkE+8PgvtMkyMDi9CBb4THrlZPRl1rJyxJOOCGlV144kdMQX X-Received: by 2002:a17:906:f189:: with SMTP id gs9mr3065445ejb.203.1592319668060; Tue, 16 Jun 2020 08:01:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592319668; cv=none; d=google.com; s=arc-20160816; b=Q5/G5NDDMpSITF+SFotDLuUQqaY3eWPDbaRCgVjT4xO1ujXJoauUtMXjVSMjhbrNtL fdCqP0dxTl0T/LH21wEC2vndjlyHs1SfWABb5DxpaQXhn/qt1uZPDqrDAXrhPDuXpH7J PMoMum32rNByGvosMJ0Lrda8uejHrmm/ShHtzQTxHqbp0TeziGKzs99accWY8MWuRVFi V/+KE29p7E4jUIs3urzhN7FRCqfEpRFx49FUIB3Be1TGTH2HBFFeYop9+OsYqRNjxxb7 pfaRIqtO43VndWga3pOeO6bQrFx7VKP9poCkr4yS224WEoVtm28sO/vUcA1zhJEDQXv7 mQsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=LACSqH61luxbPNvpi+PVlgHG+Wllm+t/k4pHVpdDnuo=; b=jU0jD5pz9kemkRaFmbXjevUDlEKaSWO416M3wFjc3T0DDKgTRSKsDaZ4bIVY8prXBJ /d2Wh5QdZwuf0KrSuLy99mwPd4MZ2aWPQOspgaB2xhlhJa4uXte6LCuyASdADlJ5U23s cWKmIKp8SEBEdccD3JgV+E1TlIZxt5TtCXpesu/L6HoDG1DiVOpvJ/593uOlVBEmmVhH nhVFTJd9crht5Gvtg+4FJLBHhfHTPjMIUMIRZbxoeEnooiD6I8nd4Eo/tQC00ZMPLnev 2XWeHRUTx9fCBxONOSbovAaj1y5HGnC622d/rb/Fnh5TRrmDSGqBILk6frfgrBpJXFSo gr5A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bu21si11325570ejb.675.2020.06.16.08.00.45; Tue, 16 Jun 2020 08:01:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729177AbgFPO7E (ORCPT + 99 others); Tue, 16 Jun 2020 10:59:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:57634 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727804AbgFPO7D (ORCPT ); Tue, 16 Jun 2020 10:59:03 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8682220644; Tue, 16 Jun 2020 14:59:02 +0000 (UTC) Date: Tue, 16 Jun 2020 10:59:00 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Lichao Liu , mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, bsegall@google.com, mgorman@suse.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/rt: Don't active rt throtting when no running cfs task Message-ID: <20200616105900.5cb0671d@oasis.local.home> In-Reply-To: <20200616140158.GY2531@hirez.programming.kicks-ass.net> References: <20200616123729.153430-1-liulichao@loongson.cn> <20200616095027.1a2048d0@oasis.local.home> <20200616140158.GY2531@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 16 Jun 2020 16:01:58 +0200 Peter Zijlstra wrote: > On Tue, Jun 16, 2020 at 09:50:27AM -0400, Steven Rostedt wrote: > > On Tue, 16 Jun 2020 20:37:29 +0800 > > Lichao Liu wrote: > > > > > Active rt throtting will dequeue rt_rq from rq at least 50ms, > > > When there is no running cfs task, do we still active it? > > > > > > > This is something I would like to have. > > > > Peter, what's your thought on this? > > I'd love to just delete all of this.. that said, I'm not sure this > change makes sense, because it doesn't deal sanely with the case where > the task will appear right after we did this. I haven't looked closely at the surrounding code, but wouldn't it get throttled in the next period? Do we care if a task has to wait a bit longer? > > The right thing to do is that fair deadline server thing. But we've been saying that for years now. -- Steve