Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7480721imu; Tue, 22 Jan 2019 06:45:33 -0800 (PST) X-Google-Smtp-Source: ALg8bN74/DCQdzgCp6epOOMX36omf9Duf1dYtt9rpt/Ns71IbWEM8HwwGZ/NZwzrioi3JqE1QoA3 X-Received: by 2002:a63:de46:: with SMTP id y6mr32134695pgi.198.1548168333100; Tue, 22 Jan 2019 06:45:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548168333; cv=none; d=google.com; s=arc-20160816; b=ZciYlbk8yy4hfUuuGtu6VckcLohuNodGZsU/2csuqRvj6EOhLYWbhjhtRn4FzLxT4Y t/gturCKfEJdSpAnuau4NyKX/bAu/fSA5VfWBoRwnbzb/fTpA9bWA9k6eYKjzbQJBk74 ywd5EP7jXCBvNc3Xf0bCRinHUmqoiSYKX7ODeUzHfnUYoa1kE4HkEVwk9UwEdr6XhDm2 REsvL0JHbDB7u7guH/Y2EnDjRikleZMORIfEBj/64w8YVa1tHOIrA52+o6UDMsi46PMR ci6ptUrGUPGWOKY3ddjKATFqzUCvZlr9Wl/1c8TEB6PUuhXyvT0tDPLTBwof9RdYz7q6 hLMA== 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=yopuEyyG5UeQufGDnVgaVOEdctViWiR7Q8mAfqUnXnU=; b=Vz4JdMl8fRT2c5S9NmoxjcL1lReAvumBSLJB9hOofeCf8ow5DICHdlPJI9gmaO5roE 0JLDnELq5cE/qOjpftP8Q95y9I1t/vFkJXyCQYedI73Z3rUShH/6kykhGLhUn0OzH+wh xDWELf7eKXgDBtghBkZ+NRc2EETNv0lX6u+xURGRBRUvGfm3TgTRW/R4naPyfuulksSS LBQwIyhKsLDtB45e8S8xQ7vNP/SVz3nOuDNpnLpEDA/+CbMF7lLaW/hNSfUrprBwrybB YUFiGsyhEFzFw6vO1g/rj9wCDlKtQdirabDIEkENqzLBBH8PPteYW2GnhqH/kP5M5V6G ZvSw== 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 e1si2856262pln.55.2019.01.22.06.45.17; Tue, 22 Jan 2019 06:45:33 -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 S1728872AbfAVOnf (ORCPT + 99 others); Tue, 22 Jan 2019 09:43:35 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:54728 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728712AbfAVOnf (ORCPT ); Tue, 22 Jan 2019 09:43:35 -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 2D50BA78; Tue, 22 Jan 2019 06:43:35 -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 3835C3F589; Tue, 22 Jan 2019 06:43:32 -0800 (PST) Date: Tue, 22 Jan 2019 14:43:29 +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 07/16] sched/core: uclamp: Add system default clamps Message-ID: <20190122144329.ziimv6fejwvky7yb@e110439-lin> References: <20190115101513.2822-1-patrick.bellasi@arm.com> <20190115101513.2822-8-patrick.bellasi@arm.com> <20190122135644.GP27931@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190122135644.GP27931@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 14:56, Peter Zijlstra wrote: > On Tue, Jan 15, 2019 at 10:15:04AM +0000, Patrick Bellasi wrote: > > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > index 84294925d006..c8f391d1cdc5 100644 > > --- a/include/linux/sched.h > > +++ b/include/linux/sched.h > > @@ -625,6 +625,11 @@ struct uclamp_se { > > unsigned int bucket_id : bits_per(UCLAMP_BUCKETS); > > unsigned int mapped : 1; > > unsigned int active : 1; > > + /* Clamp bucket and value actually used by a RUNNABLE task */ > > + struct { > > + unsigned int value : bits_per(SCHED_CAPACITY_SCALE); > > + unsigned int bucket_id : bits_per(UCLAMP_BUCKETS); > > + } effective; > > I am confuzled by this thing.. so uclamp_se already has a value,bucket, > which per the prior code is the effective one. > > Now; I think I see why you want another value; you need the second to > store the original value for when the system limits change and we must > re-evaluate. Yes, that's one reason, the other one being to properly support CGroup when we add them in the following patches. Effective will always track the value/bucket in which the task has been refcounted at enqueue time and it depends on the aggregated value. > So why are you not adding something like: > > unsigned int orig_value : bits_per(SCHED_CAPACITY_SCALE); Would say that can be enough if we decide to ditch the mapping and use a linear mapping. In that case the value will always be enough to find in which bucket a task has been accounted. > > +unsigned int sysctl_sched_uclamp_util_min; > > > +unsigned int sysctl_sched_uclamp_util_max = SCHED_CAPACITY_SCALE; > > > +static inline void > > +uclamp_effective_get(struct task_struct *p, unsigned int clamp_id, > > + unsigned int *clamp_value, unsigned int *bucket_id) > > +{ > > + /* Task specific clamp value */ > > + *clamp_value = p->uclamp[clamp_id].value; > > + *bucket_id = p->uclamp[clamp_id].bucket_id; > > + > > + /* System default restriction */ > > + if (unlikely(*clamp_value < uclamp_default[UCLAMP_MIN].value || > > + *clamp_value > uclamp_default[UCLAMP_MAX].value)) { > > + /* Keep it simple: unconditionally enforce system defaults */ > > + *clamp_value = uclamp_default[clamp_id].value; > > + *bucket_id = uclamp_default[clamp_id].bucket_id; > > + } > > +} > > That would then turn into something like: > > unsigned int high = READ_ONCE(sysctl_sched_uclamp_util_max); > unsigned int low = READ_ONCE(sysctl_sched_uclamp_util_min); > > uclamp_se->orig_value = value; > uclamp_se->value = clamp(value, low, high); > > And then determine bucket_id based on value. Right... if I ditch the mapping that should work. > > +int sched_uclamp_handler(struct ctl_table *table, int write, > > + void __user *buffer, size_t *lenp, > > + loff_t *ppos) > > +{ > > + int old_min, old_max; > > + int result = 0; > > + > > + mutex_lock(&uclamp_mutex); > > + > > + old_min = sysctl_sched_uclamp_util_min; > > + old_max = sysctl_sched_uclamp_util_max; > > + > > + result = proc_dointvec(table, write, buffer, lenp, ppos); > > + if (result) > > + goto undo; > > + if (!write) > > + goto done; > > + > > + if (sysctl_sched_uclamp_util_min > sysctl_sched_uclamp_util_max || > > + sysctl_sched_uclamp_util_max > SCHED_CAPACITY_SCALE) { > > + result = -EINVAL; > > + goto undo; > > + } > > + > > + if (old_min != sysctl_sched_uclamp_util_min) { > > + uclamp_bucket_inc(NULL, &uclamp_default[UCLAMP_MIN], > > + UCLAMP_MIN, sysctl_sched_uclamp_util_min); > > + } > > + if (old_max != sysctl_sched_uclamp_util_max) { > > + uclamp_bucket_inc(NULL, &uclamp_default[UCLAMP_MAX], > > + UCLAMP_MAX, sysctl_sched_uclamp_util_max); > > + } > > Should you not update all tasks? That's true, but that's also an expensive operation, that's why now I'm doing only lazy updates at next enqueue time. Do you think that could be acceptable? Perhaps I can sanity check all the CPU to ensure that they all have a current clamp value within the new enforced range. This kind-of anticipate the idea to have an in-kernel API which has higher priority and allows to set clamp values across all the CPUs... -- #include Patrick Bellasi