Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1958866ybl; Thu, 9 Jan 2020 04:38:32 -0800 (PST) X-Google-Smtp-Source: APXvYqzvfeCvo/beDgDFcYeLGIaC32q2CB1yB9KqqQrqvQa/K2zPoDE29/1gNPWKOA2hQuSKQYs0 X-Received: by 2002:aca:50cd:: with SMTP id e196mr2936540oib.178.1578573512442; Thu, 09 Jan 2020 04:38:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578573512; cv=none; d=google.com; s=arc-20160816; b=oDBEEix71gfyzaeG/zAxf0zDvJgm+9gjcRk4fVJjW0qGuW94DT/MoSSYSEwa1gDkXm kmBX7yVp8T48XNnnuADjRe+gppOK/lyx7zQVBvVE+NjbEU8grDV761K3pUL+GiOGtPBF Wh6E6kA1KEH1V59h7gEa1axPzxhs0mh3dUADZHVz+JFuHkaUG02Y70kNi/VlqGneqsAk WBJGHF51xhFb2aGeL0WQzo9p+m4UFK8NdgFe+Z39AReuzT8tdD0O7KmvVVVCiTK7RM9j sus+BYdKxIgUNdAogiEBZFoFBiCbSwrQTHQM+Wp4prNWXO+Hj68WuM9RMjFUbEouiq4E ZzRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Y+niXVoN/P1QTElmHSdRM2QqkO3qGiLLAwISTHDiivQ=; b=WS+syM1xrWe+mCACmr+h8dTA0LZaXCB7sTZfnH4/CUU1o2XeXcrUkDYMVkFnp+T4FZ t7ve9//fNao2Bm4oBQzkH3dhKqGZ2ox3Dc8KDxDVf/tIiMCvEVeQaf3amrKUEAybdKIe 9a73X/sMFStOmu3Hh+iEP7+ODzz8kVKROTbHJrUxKcgE/WhTe0eSoVSAsu+b4MiOVDFS UZQlrEsbCl0XYjFZUrtJk6Hkq0jK/IIE05zUIPlsbgA/I8rqZpcq8rDFu6nyQNtUsBTf 1GQLQ7sSGMeBheqyNTXV3W833YZef9rqyhbx/HLY00lkHzMUkTPOWcAKU2dwNRJAc9zP jPKQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j19si3447305oij.51.2020.01.09.04.38.20; Thu, 09 Jan 2020 04:38:32 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725840AbgAILgb (ORCPT + 99 others); Thu, 9 Jan 2020 06:36:31 -0500 Received: from foss.arm.com ([217.140.110.172]:57584 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725308AbgAILga (ORCPT ); Thu, 9 Jan 2020 06:36:30 -0500 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 C0A0831B; Thu, 9 Jan 2020 03:36:27 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A80053F703; Thu, 9 Jan 2020 03:36:25 -0800 (PST) Date: Thu, 9 Jan 2020 11:36:23 +0000 From: Qais Yousef To: Quentin Perret Cc: Dietmar Eggemann , Ingo Molnar , Peter Zijlstra , Steven Rostedt , Luis Chamberlain , Kees Cook , Iurii Zaikin , Juri Lelli , Vincent Guittot , Ben Segall , Mel Gorman , valentin.schneider@arm.com, Patrick Bellasi , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH] sched/rt: Add a new sysctl to control uclamp_util_min Message-ID: <20200109113623.jk4yth6koyq2wwh7@e107158-lin.cambridge.arm.com> References: <20191220164838.31619-1-qais.yousef@arm.com> <20200107134234.GA158998@google.com> <8bb17e84-d43f-615f-d04d-c36bb6ede5e0@arm.com> <20200108095108.GA153171@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200108095108.GA153171@google.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/08/20 09:51, Quentin Perret wrote: > On Tuesday 07 Jan 2020 at 20:30:36 (+0100), Dietmar Eggemann wrote: > > On 07/01/2020 14:42, Quentin Perret wrote: > > > Hi Qais, > > > > > > On Friday 20 Dec 2019 at 16:48:38 (+0000), Qais Yousef wrote: > > > > [...] > > > > >> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c > > >> index e591d40fd645..19572dfc175b 100644 > > >> --- a/kernel/sched/rt.c > > >> +++ b/kernel/sched/rt.c > > >> @@ -2147,6 +2147,12 @@ static void pull_rt_task(struct rq *this_rq) > > >> */ > > >> static void task_woken_rt(struct rq *rq, struct task_struct *p) > > >> { > > >> + /* > > >> + * When sysctl_sched_rt_uclamp_util_min value is changed by the user, > > >> + * we apply any new value on the next wakeup, which is here. > > >> + */ > > >> + uclamp_rt_sync_default_util_min(p); > > > > > > The task has already been enqueued and sugov has been called by then I > > > think, so this is a bit late. You could do that in uclamp_rq_inc() maybe? > > > > That's probably better. > > Just to be sure ...we want this feature (an existing rt task gets its > > UCLAMP_MIN value set when the sysctl changes) because there could be rt > > tasks running before the sysctl is set? > > Yeah, I was wondering the same thing, but I'd expect sysadmin to want > this. We could change the min clamp of existing RT tasks in userspace > instead, but given how simple Qais' lazy update code is, the in-kernel > looks reasonable to me. No strong opinion, though. The way I see this being used is set in init.rc. If any RT tasks were created (most likely kthreads) before that they'll just be updated on the next wakeup. Of course this approach allows the value to change any point of time when the system is running without having to do a reboot/recompile or kick a special script/app to modify all existing RT tasks and continuously monitor new ones. Another advantage is that apps that have special requirement (like professional audio) can use the per-task uclamp API to bump their uclamp_min without conflicting with the desired generic value for all other RT tasks. IOW, we can easily at run time control the baseline performance for RT tasks with a single knob without interfering with RT tasks that opt-in to modify their own uclamp values. -- Qais Yousef