Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7537584imu; Tue, 22 Jan 2019 07:34:50 -0800 (PST) X-Google-Smtp-Source: ALg8bN4tKggBfsn1SY95LXrPF1X9/OmDQjAF3s/rVmh+SK9U9GNChMvYKEdjDu4PlelRClLgUq39 X-Received: by 2002:a17:902:5ac2:: with SMTP id g2mr34791022plm.313.1548171290108; Tue, 22 Jan 2019 07:34:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548171290; cv=none; d=google.com; s=arc-20160816; b=gIMzgyxIdgh0f8exHvExfKOyLtCfJDrKnj0nYiXkMfTh48pOifn4HhZnjWq7+p2+st ZvtNAFqiYnQAL56GvrxapueOLE0vtosI6TudI1DjTpUGkGmE+mZtP0361Xt92ljqBlYK U0OLDQcv4Fj30Oq2oNgeeKXzKgzoyXLGds5KixUEFZodP2043LsKru6oj+wv+NFRIJuF sklognrgkAH8GGDmfxVDNFxaAO6mywU9apaY7GGHaOpSyBJGdbhFqqMHX5QKkgQy5546 6cNSoqSIZaicPR8vf+l8QVLvqJIyE5Gxa3WwFRm4I8SOVtmRnkdTK7gpEXF9sjr1HQGE fL0Q== 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=/NVzo/HGZHmiy0PzjneIysixoo56EMniVaqmK3irDfs=; b=XOioV79wZUfkiRcSGDwiPuwdpbSaSwGcwTxgCXxKJJVCCKZuudOUKmZg1YpLNH5wg2 v/LucVu3wMprflE97XIsT2rebro2o1B93qQugSshsNORDBn0fyBdUxTSQIRyPSRvfMqQ HCEggCtuU5U2Z4bgwaXN+XZMSw0eNaMG9hhnB5pYp93TiFlXosumm94DKV+h7RJCJeAf 1bAK7P1I9PP+rLeDU+tvSYq/LloGcj/Ky+QN0B559BrZSA4+IGxkEGSwK4HcLdv2iO2b DI6buY9syeR105FZvru7iaS8TnlzVoiU3pXcziMiDy4qTEJrdKmuodfh/lqsdcA8Jnwb fgOg== 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 89si15455605pfr.242.2019.01.22.07.34.33; Tue, 22 Jan 2019 07:34:50 -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 S1728745AbfAVPdV (ORCPT + 99 others); Tue, 22 Jan 2019 10:33:21 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:56096 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728601AbfAVPdV (ORCPT ); Tue, 22 Jan 2019 10:33:21 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A981CA78; Tue, 22 Jan 2019 07:33:20 -0800 (PST) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.194.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B59BC3F589; Tue, 22 Jan 2019 07:33:17 -0800 (PST) Date: Tue, 22 Jan 2019 15:33:15 +0000 From: Patrick Bellasi To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-api@vger.kernel.org, Ingo Molnar , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v6 05/16] sched/core: uclamp: Update CPU's refcount on clamp changes Message-ID: <20190122153315.dhjl67sgpu74hmqv@e110439-lin> References: <20190115101513.2822-1-patrick.bellasi@arm.com> <20190115101513.2822-6-patrick.bellasi@arm.com> <20190121153308.GL27931@hirez.programming.kicks-ass.net> <20190121154412.fak2t2iquj3aixtu@e110439-lin> <20190122093704.GM27931@hirez.programming.kicks-ass.net> <20190122104305.6vjx37muqsxm536t@e110439-lin> <20190122132817.GG13777@hirez.programming.kicks-ass.net> <20190122140115.twtx646vewm757ca@e110439-lin> <20190122145742.GQ27931@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190122145742.GQ27931@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22-Jan 15:57, Peter Zijlstra wrote: > On Tue, Jan 22, 2019 at 02:01:15PM +0000, Patrick Bellasi wrote: > > On 22-Jan 14:28, Peter Zijlstra wrote: > > > On Tue, Jan 22, 2019 at 10:43:05AM +0000, Patrick Bellasi wrote: > > > > On 22-Jan 10:37, Peter Zijlstra wrote: > > > > > > > > Sure, I get that. What I don't get is why you're adding that (2) here. > > > > > Like said, __sched_setscheduler() already does a dequeue/enqueue under > > > > > rq->lock, which should already take care of that. > > > > > > > > Oh, ok... got it what you mean now. > > > > > > > > With: > > > > > > > > [PATCH v6 01/16] sched/core: Allow sched_setattr() to use the current policy > > > > <20190115101513.2822-2-patrick.bellasi@arm.com> > > > > > > > > we can call __sched_setscheduler() with: > > > > > > > > attr->sched_flags & SCHED_FLAG_KEEP_POLICY > > > > > > > > whenever we want just to change the clamp values of a task without > > > > changing its class. Thus, we can end up returning from > > > > __sched_setscheduler() without doing an actual dequeue/enqueue. > > > > > > I don't see that happening.. when KEEP_POLICY we set attr.sched_policy = > > > SETPARAM_POLICY. That is then checked again in __setscheduler_param(), > > > which is in the middle of that dequeue/enqueue. > > > > Yes, I think I've forgot a check before we actually dequeue the task. > > > > The current code does: > > > > ---8<--- > > SYSCALL_DEFINE3(sched_setattr) > > > > // A) request to keep the same policy > > if (attr.sched_flags & SCHED_FLAG_KEEP_POLICY) > > attr.sched_policy = SETPARAM_POLICY; > > > > sched_setattr() > > // B) actually enforce the same policy > > if (policy < 0) > > policy = oldpolicy = p->policy; > > > > // C) tune the clamp values > > if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP) > > retval = __setscheduler_uclamp(p, attr); > > > > // D) tune attributes if policy is the same > > if (unlikely(policy == p->policy)) > > if (fair_policy(policy) && attr->sched_nice != task_nice(p)) > > goto change; > > if (rt_policy(policy) && attr->sched_priority != p->rt_priority) > > goto change; > > if (dl_policy(policy) && dl_param_changed(p, attr)) > > goto change; > > if (util_changed) > goto change; > > ? > > > return 0; > > change: > > > > // E) dequeue/enqueue task > > ---8<--- > > > > So, probably in D) I've missed a check on SCHED_FLAG_KEEP_POLICY to > > enforce a return in that case... > > > > > Also, and this might be 'broken', SETPARAM_POLICY _does_ reset all the > > > other attributes, it only preserves policy, but it will (re)set nice > > > level for example (see that same function). > > > > Mmm... right... my bad! :/ > > > > > So maybe we want to introduce another (few?) FLAG_KEEP flag(s) that > > > preserve the other bits; I'm thinking at least KEEP_PARAM and KEEP_UTIL > > > or something. > > > > Yes, I would say we have two options: > > > > 1) SCHED_FLAG_KEEP_POLICY enforces all the scheduling class specific > > attributes, but cross class attributes (e.g. uclamp) > > > > 2) add SCHED_KEEP_NICE, SCHED_KEEP_PRIO, and SCED_KEEP_PARAMS > > and use them in the if conditions in D) > > So the current KEEP_POLICY basically provides sched_setparam(), and But it's not exposed user-space. > given we have that as a syscall, that is supposedly a useful > functionality. For uclamp is definitively useful to change clamps without the need to read beforehand the current policy params and use them in a following set syscall... which is racy pattern. > Also, NICE/PRIO/DL* is all the same thing and depends on the policy, > KEEP_PARAM should cover the lot Right, that makes sense. > And I suppose the UTIL_CLAMP is !KEEP_UTIL; we could go either way > around with that flag. What about getting rid of the racy case above by exposing userspace only the new UTIL_CLAMP and, on: sched_setscheduler(flags: UTIL_CLAMP) we enforce the other two flags from the syscall: ---8<--- SYSCALL_DEFINE3(sched_setattr) if (attr.sched_flags & SCHED_FLAG_KEEP_POLICY) { attr.sched_policy = SETPARAM_POLICY; attr.sched_flags |= (KEEP_POLICY|KEEP_PARAMS); } ---8<--- This will not make possible to change class and set flags in one go, but honestly that's likely a very limited use-case, isn't it ? > > In both cases the goal should be to return from code block D). > > I don't think so; we really do want to 'goto change' for util changes > too I think. Why duplicate part of that logic? But that will force a dequeue/enqueue... isn't too much overhead just to change a clamp value? Perhaps we can also end up with some wired side-effects like the task being preempted ? Consider also that the uclamp_task_update_active() added by this patch not only has lower overhead but it will be use also by cgroups where we want to force update all the tasks on a cgroup's clamp change. -- #include Patrick Bellasi