[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201113122632.jydnt2o7ipp4ntli@e107158-lin.cambridge.arm.com>
Date: Fri, 13 Nov 2020 12:26:32 +0000
From: Qais Yousef <qais.yousef@....com>
To: Dietmar Eggemann <dietmar.eggemann@....com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Yun Hsiang <hsiang023167@...il.com>,
linux-kernel@...r.kernel.org, patrick.bellasi@...bug.net,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v5 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET
flag to reset uclamp
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
Powered by blists - more mailing lists