Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1090434pxb; Fri, 13 Nov 2020 04:06:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJzws06Uxyfk62ceZbnpYzDVTx9Nc4eHU5T0TMvML38kuPXl+fAD5Zoe17oDIzuiz+UeFHwF X-Received: by 2002:a17:906:7c54:: with SMTP id g20mr1535431ejp.105.1605269164020; Fri, 13 Nov 2020 04:06:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605269164; cv=none; d=google.com; s=arc-20160816; b=cYquUfywMZ9UMhlEE7LE/vZygoe7sroxsMzqU5hQ8AlZ/sBQTMTWXPOou8X38CzuiM dDHz1GLaAzio2IXVk+QDuOEYz/KPB31RUjiEAiZjR06Rbv3EZy/BQHgFMZgLyUhwlECw psF9pokv0wrd2saNp0G95uP3NH+QAeIvMM2+9aLUsBRqehaTsDjBqDW8kTjfREV1okIZ nniXv9cAyRwjOn2isCbBmk158OBoX4xTxl8bLXisGHWVP72A0KEibrCselmLj4ILz/tM TUJqdR+ddNRuDT2245pyracGfTLRoxcNO57Ng0BzPDBIshPvZ+5vbG7HftQ6+JQUNQwX OnUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=gW6F3W7K9YoqD6slruOTzZPQf0/aIQLWFGS9q/8s2dA=; b=azwdxM18a7hYCMCYOEERt82BeHs2Y3Lb2boowZxHk5DfzTdcY4m3FT3RpLHlAVh+23 ZsQhUzA7NhY2B1kI+kaSQtttw+HD0qPbVC0vz0viV9j7UxxCBWYlHyPfJeMmzVIdtHw1 YOKmSSavJ6Ve5LXzZ4Bk+27ts2d7sXt0WvNnjKNo+prOLbFESl0TPz8/BcxRfQpjyBb6 oPCTMNrkw9t1o2mbpusw+fiGQUBDaX1qWWa5V136UZd0KGtJuHWRIOQw3+cNCd8mzuyP N8Wq/JVcLG55cDT0UmRelughk7GL9VeODd6btD/6WhVHxlW1xAXgql9VvqNFwHqE+RdL TMAg== 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 lr26si5434351ejb.747.2020.11.13.04.05.38; Fri, 13 Nov 2020 04:06:04 -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 S1726829AbgKMMDZ (ORCPT + 99 others); Fri, 13 Nov 2020 07:03:25 -0500 Received: from foss.arm.com ([217.140.110.172]:36800 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726776AbgKMLpd (ORCPT ); Fri, 13 Nov 2020 06:45:33 -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 A4E961042; Fri, 13 Nov 2020 03:45:32 -0800 (PST) Received: from [192.168.178.2] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 485733F6CF; Fri, 13 Nov 2020 03:45:31 -0800 (PST) Subject: Re: [PATCH v5 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag to reset uclamp From: Dietmar Eggemann To: Qais Yousef Cc: Peter Zijlstra , Yun Hsiang , linux-kernel@vger.kernel.org, patrick.bellasi@matbug.net, kernel test robot References: <20201103023756.1012088-1-hsiang023167@gmail.com> <20201110122108.GG2594@hirez.programming.kicks-ass.net> <20201112144131.7gqglj435bs6otwm@e107158-lin.cambridge.arm.com> Message-ID: <131cb7b5-e400-11e1-8fc1-b6e8183f1a8d@arm.com> Date: Fri, 13 Nov 2020 12:45:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.