From: Qais Yousef <qais.yousef@arm.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Yun Hsiang <hsiang023167@gmail.com>,
linux-kernel@vger.kernel.org, patrick.bellasi@matbug.net,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v5 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag to reset uclamp
Date: Fri, 13 Nov 2020 12:26:32 +0000 [thread overview]
Message-ID: <20201113122632.jydnt2o7ipp4ntli@e107158-lin.cambridge.arm.com> (raw)
In-Reply-To: <131cb7b5-e400-11e1-8fc1-b6e8183f1a8d@arm.com>
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
prev parent reply other threads:[~2020-11-13 12:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-03 2:37 Yun Hsiang
2020-11-03 13:46 ` Qais Yousef
2020-11-03 13:48 ` Qais Yousef
2020-11-04 9:45 ` Dietmar Eggemann
2020-11-07 18:24 ` Yun Hsiang
2020-11-06 10:36 ` Patrick Bellasi
2020-11-07 19:15 ` Yun Hsiang
2020-11-09 13:41 ` Qais Yousef
2020-11-10 12:18 ` Peter Zijlstra
2020-11-10 12:21 ` Peter Zijlstra
2020-11-11 17:41 ` Dietmar Eggemann
2020-11-11 18:04 ` Peter Zijlstra
2020-11-12 5:44 ` Yun Hsiang
2020-11-12 13:05 ` Dietmar Eggemann
2020-11-12 14:41 ` Qais Yousef
2020-11-12 16:01 ` Dietmar Eggemann
2020-11-13 11:45 ` Dietmar Eggemann
2020-11-13 12:26 ` Qais Yousef [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201113122632.jydnt2o7ipp4ntli@e107158-lin.cambridge.arm.com \
--to=qais.yousef@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=hsiang023167@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®