Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 6 Apr 2023 09:33:30 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     David Dai <davidai@google.com>
Cc:     Ingo Molnar <mingo@redhat.com>, Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        Saravana Kannan <saravanak@google.com>,
        kernel-team@android.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/6] sched/fair: Add util_guest for tasks
Message-ID: <20230406073330.GA386572@hirez.programming.kicks-ass.net>
References: <20230330224348.1006691-1-davidai@google.com>
 <20230330224348.1006691-2-davidai@google.com>
 <20230405081449.GX4253@hirez.programming.kicks-ass.net>
 <CABN1KCLjXpxNak90iowd0iiz9SD8-5n+6S3kEoCKO9NantyXxg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABN1KCLjXpxNak90iowd0iiz9SD8-5n+6S3kEoCKO9NantyXxg@mail.gmail.com>
Precedence: bulk

On Wed, Apr 05, 2023 at 03:54:08PM -0700, David Dai wrote:
> On Wed, Apr 5, 2023 at 1:14 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> 
> Hi Peter,
> 
> Appreciate your time,
> 
> > On Thu, Mar 30, 2023 at 03:43:36PM -0700, David Dai wrote:
> > > @@ -499,6 +509,7 @@ struct sched_avg {
> > >       unsigned long                   load_avg;
> > >       unsigned long                   runnable_avg;
> > >       unsigned long                   util_avg;
> > > +     unsigned long                   util_guest;
> > >       struct util_est                 util_est;
> > >  } ____cacheline_aligned;
> > >
> >
> > Yeah, no... you'll have to make room first.
> >
> 
> I’m not sure what you mean. Do you mean making room by reducing
> another member in the same struct? If so, which member would be a good
> fit to shorten? Or do you mean something else entirely?

Yeah, as you can see below, this structure is completely filling up the
cacheline already so there's no room for another member. I've not looked
at this in detail in a little while so I'm not at all sure what would be
the easiest way to free up space.

Going by the rest of the discusion is seems this is the least of your
problems though.

> > struct sched_avg {
> >         /* typedef u64 -> __u64 */ long long unsigned int     last_update_time;          /*     0     8 */
> >         /* typedef u64 -> __u64 */ long long unsigned int     load_sum;                  /*     8     8 */
> >         /* typedef u64 -> __u64 */ long long unsigned int     runnable_sum;              /*    16     8 */
> >         /* typedef u32 -> __u32 */ unsigned int               util_sum;                  /*    24     4 */
> >         /* typedef u32 -> __u32 */ unsigned int               period_contrib;            /*    28     4 */
> >         long unsigned int          load_avg;                                             /*    32     8 */
> >         long unsigned int          runnable_avg;                                         /*    40     8 */
> >         long unsigned int          util_avg;                                             /*    48     8 */
> >         struct util_est {
> >                 unsigned int       enqueued;                                             /*    56     4 */
> >                 unsigned int       ewma;                                                 /*    60     4 */
> >         } __attribute__((__aligned__(8)))util_est __attribute__((__aligned__(8))); /*    56     8 */
> >
> >         /* size: 64, cachelines: 1, members: 9 */
> >         /* forced alignments: 1 */
> > } __attribute__((__aligned__(64)));
> >
> >