Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1105697pxb; Fri, 13 Nov 2020 04:31:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJyE0Sv3kaHGlMwgmf3/kXMXkuF3/3X+j783ynY7+T8aTZxhCDMj0Db9JTHQ+QGXFvM9fVtr X-Received: by 2002:a17:906:a011:: with SMTP id p17mr1710077ejy.119.1605270661229; Fri, 13 Nov 2020 04:31:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605270661; cv=none; d=google.com; s=arc-20160816; b=vMzua/CttsoD24XvNBg8ziXedRk4yPiWSNksUT+TpQodbZPqYc0g0GtfczRyXGS+HK AnF+kxfahkcJDiL3vIcmYsuuEaN00appbHWOjOwGygTZ52bqqphPNA9sRuucS31tzh7j WycEcGNxJy/9xfw0J0yTo6ImLz4eIGi7KpFvs4ZlxB9gNs09km/J//Yg1k107CArHv3J +pM9MrGbKupDTq76yTlP1yvk204BXEb4G4h+4L+UuIttGT+8LEZiJuMwY5RVvlEheVz+ gfRhteZ5prJ/qeluIq5ZG9Nlg45hOzffDissXFG7h9Q3h16mLeMHdaHyEhPpOaw8blPN PVCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=2yshjE1D4zzccHoFvlCcnPJQMFMJ9NPNj125JC43G/g=; b=zJyZ2wP2VaXWOJ+7CykszzUHrziMZN+Is0+J822mXM831FfpAJxTwt8c4levWyO24e imJqD7PR8f6k0673zVbO0+QH0yBounSYOYTj2OWrAl2J41pfCsFQ49dWMgq901EXoZ0T 1rTewB1CrLDk+UF2F1FrXFgaEWDrls3NnmbmEHakIh6IHznQu/vX41hEJXZJnN1/A8wn 97AOoL0hR4RXdyY3BhIwoci9y2+VlmKk27s0PCuTwBZP+x0kzmN7WrKIZ6rVaOoiLPkB kUsscq2clr1CDl3hWUUfECpzpTozjXK1YWLtroAO60HfJYrsj2Wv8ZUMvlNPQ5Ybnfyi BBsw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d14si6189084edu.275.2020.11.13.04.30.38; Fri, 13 Nov 2020 04:31:01 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726648AbgKMM0h (ORCPT + 99 others); Fri, 13 Nov 2020 07:26:37 -0500 Received: from foss.arm.com ([217.140.110.172]:37258 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726279AbgKMM0g (ORCPT ); Fri, 13 Nov 2020 07:26:36 -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 F2F29142F; Fri, 13 Nov 2020 04:26:35 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.194.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F2D763F6CF; Fri, 13 Nov 2020 04:26:34 -0800 (PST) Date: Fri, 13 Nov 2020 12:26:32 +0000 From: Qais Yousef To: Dietmar Eggemann Cc: Peter Zijlstra , Yun Hsiang , linux-kernel@vger.kernel.org, patrick.bellasi@matbug.net, kernel test robot Subject: Re: [PATCH v5 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag to reset uclamp Message-ID: <20201113122632.jydnt2o7ipp4ntli@e107158-lin.cambridge.arm.com> References: <20201103023756.1012088-1-hsiang023167@gmail.com> <20201110122108.GG2594@hirez.programming.kicks-ass.net> <20201112144131.7gqglj435bs6otwm@e107158-lin.cambridge.arm.com> <131cb7b5-e400-11e1-8fc1-b6e8183f1a8d@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <131cb7b5-e400-11e1-8fc1-b6e8183f1a8d@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/13/20 12:45, Dietmar Eggemann wrote: > On 12/11/2020 17:01, Dietmar Eggemann wrote: > > On 12/11/2020 15:41, Qais Yousef wrote: > >> On 11/11/20 18:41, Dietmar Eggemann wrote: > >>> On 10/11/2020 13:21, Peter Zijlstra wrote: > >>>> On Tue, Nov 03, 2020 at 10:37:56AM +0800, Yun Hsiang wrote: > > [...] > > >> If you or Yun would still like to send the patch to protect > >> SCHED_FLAG_UTIL_CLAMP and SCHED_FLAG_ALL with __kernel__ that'd be great. > > > > Ah yes! Can add an extra patch for this when sending out the next version. > > On second thought, why should we risk a change in UAPI? Since we're now > not introducing a new flag the meaning of SCHED_FLAG_ALL or > SCHED_FLAG_UTIL_CLAMP won't change. It's a judgement call. Hide them now where it's likely there are no users and hope we won't have to revert it. Or just ignore it and treat it as an ABI and make sure no one change them later. My judgement call it's better to introduce the __kernel__ while we can. But I can't say for sure nothing will break. All I know it'd be easy to revert if it does cause breakage. You get to choose :-) Thanks -- Qais Yousef