From: Peter Zijlstra <peterz@infradead.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Dietmar Eggemann <Dietmar.Eggemann@arm.com>,
Tejun Heo <tj@kernel.org>,
Patrick Bellasi <patrick.bellasi@matbug.net>,
Suren Baghdasaryan <surenb@google.com>,
Quentin Perret <qperret@google.com>,
Qais Yousef <qais.yousef@arm.com>
Subject: Re: [PATCH v2] sched/uclamp: Fix overzealous type replacement
Date: Fri, 15 Nov 2019 21:21:05 +0100 [thread overview]
Message-ID: <20191115202105.GR4131@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKfTPtCvt7BZ8g2sC3j=uoN-8nXfwRDGaO06xtHN0O+d8u5MQQ@mail.gmail.com>
On Fri, Nov 15, 2019 at 06:34:19PM +0100, Vincent Guittot wrote:
> On Fri, 15 Nov 2019 at 18:10, Valentin Schneider
> <valentin.schneider@arm.com> wrote:
> >
> > On 15/11/2019 14:29, Valentin Schneider wrote:
> > > On 15/11/2019 14:07, Vincent Guittot wrote:
> > >>> -static inline enum uclamp_id uclamp_none(enum uclamp_id clamp_id)
> > >>> +static inline unsigned int uclamp_none(enum uclamp_id clamp_id)
> > >>
> > >> Out of curiosity why uclamp decided to use unsigned int to manipulate
> > >> utilization instead of unsigned long which is the type of util_avg ?
> > >>
> > >
> > > I didn't stare at the discussion much, but I think it stems from the
> > > design choices behind struct uclamp_se: everything is crammed in an unsigned
> > > int bitfield. Let me see if I can find some relevant mails.
> > >
> >
> > So I think a relevant mail is:
> >
> > https://lore.kernel.org/lkml/20180912174236.GB24106@hirez.programming.kicks-ass.net/
> >
> > Other than that, the uclamp_se.value field was 'int' in v1 and has been
> > 'unsigned int' for all following versions. uclamp_bucket.value is a bitfield
> > of an 'unsigned long' just because we want more headroom for the tasks count,
> > AFAICT.
>
> Thanks for the pointer and deep diving in the email threads
It was all in an effort to minimize the number of cachelines touched to
maintain this data.
next prev parent reply other threads:[~2019-11-15 20:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 10:39 Valentin Schneider
2019-11-15 14:07 ` Vincent Guittot
2019-11-15 14:29 ` Valentin Schneider
2019-11-15 17:10 ` Valentin Schneider
2019-11-15 17:34 ` Vincent Guittot
2019-11-15 20:21 ` Peter Zijlstra [this message]
2019-11-15 17:38 ` Vincent Guittot
2019-11-17 9:50 ` [tip: sched/core] " tip-bot2 for Valentin Schneider
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=20191115202105.GR4131@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Dietmar.Eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=patrick.bellasi@matbug.net \
--cc=qais.yousef@arm.com \
--cc=qperret@google.com \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.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®