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;
MIME-Version: 1.0
References: <20200610151818.1.I666ecd9c6f3c6405bd75831a21001b8109b6438c@changeid>
 <20200611110301.GA132747@google.com> <CAD=FV=V2FvFcYrghxUSdHNxmcS3DKpnBbk2oL64w7hh=tV-DfQ@mail.gmail.com>
 <20200612092454.GA94228@google.com> <20200612123448.fcmzv3rdtsbawmpd@e107158-lin.cambridge.arm.com>
 <CAD=FV=UySLsTaUP3nOfQO98qPEUkY8tMhw25pJ4Yi7FVM5xU6g@mail.gmail.com> <20200619153146.vaizbj7muy52zvbd@e107158-lin.cambridge.arm.com>
In-Reply-To: <20200619153146.vaizbj7muy52zvbd@e107158-lin.cambridge.arm.com>
From:   Doug Anderson <dianders@chromium.org>
Date:   Mon, 22 Jun 2020 11:19:49 -0700
Message-ID: <CAD=FV=V0YCS69uErFnY-cF_v44mDfAe4AWa+K+U6mQR+TNLkww@mail.gmail.com>
Subject: Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump
 cpu freq
To:     Qais Yousef <qais.yousef@arm.com>
Cc:     Quentin Perret <qperret@google.com>,
        Benson Leung <bleung@chromium.org>,
        Enric Balletbo i Serra <enric.balletbo@collabora.com>,
        hsinyi@chromium.org, Joel Fernandes <joelaf@google.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Nicolas Boichat <drinkcat@chromium.org>,
        Gwendal Grignou <gwendal@chromium.org>,
        ctheegal@codeaurora.org, Guenter Roeck <groeck@chromium.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

On Fri, Jun 19, 2020 at 8:31 AM Qais Yousef <qais.yousef@arm.com> wrote:
>
> Hi Doug,
>
> On 06/18/20 14:31, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Jun 12, 2020 at 5:34 AM Qais Yousef <qais.yousef@arm.com> wrote:
> > >
> > > On 06/12/20 10:24, Quentin Perret wrote:
> > > > +CC Qais [FYI]
> > >
> > > Thanks for the CC.
> > >
> > > >
> > > > On Thursday 11 Jun 2020 at 10:48:40 (-0700), Doug Anderson wrote:
> > > > > Hrm.  I guess my first instinct is to say that we still want this
> > > > > patch even if we have something that is applied more globally.
> > > >
> > > > Fair enough.
> > > >
> > > > > Specifically it sounds as if the patch you point at is suggesting that
> > > > > we'd tweak the boost value to something other than max but we'd still
> > > > > have a boost value.  In the case of cros_ec_spi I don't believe we
> > > > > need any boost value at all, so my patch would still be useful.  The
> > > > > computational needs of cros_ec_spi are very modest and it can do its
> > > > > work at lower CPU frequencies just fine.  It just can't be interrupted
> > > > > for large swaths of time.
> > > > >
> > > > >
> > > > > > IOW, how do you feel about 20200511154053.7822-1-qais.yousef@arm.com ?
> > > > >
> > > > > I'm not totally a fan, but I'm definitely not an expert in this area
> > > > > (I've also only read the patch description and not the patch or the
> > > > > whole thread).  I really don't want yet another value that I need to
> > > > > tune from board to board.  Even worse, this tuning value isn't
> > > > > board-specific but a combination of board and software specific.  By
> > > > > this, I'd imagine a scenario where you're using a real-time task to
> > > > > get audio decoding done within a certain latency.  I guess you'd tune
> > > > > this value to make sure that you can get all your audio decoding done
> > > > > in time but also not burn extra power.  Now, imagine that the OS
> > > > > upgrades and the audio task suddenly has to decode more complex
> > > > > streams.  You've got to go across all of your boards and re-tune every
> > > > > one?  ...or, nobody thinks about it and older boards start getting
> > > > > stuttery audio?  Perhaps the opposite happens and someone comes up
> > > > > with a newer lower-cpu-intensive codec and you could save power.
> > > > > Sounds like a bit of a nightmare.
> > >
> > > Generally I would expect this global tunable to be part of a vendor's SoC BSP.
> >
> > I think I'm coming at this from a very different world than the one
> > you're thinking of.  The concept of a BSP makes me think of a SoC
> > vendor providing a drop of Linux with all their own weird hacks in it
> > that only ever works on that one SoC and will never, ever, ever be
> > updated.  5 years down the road if a software update is needed
> > (security fix?) some poor soul will be in charge of tracking down the
> > exact ancient code base that was used to build the original kernel,
> > making the tweak, and building a new kernel.  ;-)
> >
> > In the world of Chrome OS we try very very hard to build everything
> > from a clean code base and are trying hard to stay even closer to
> > upstream and away from per-device weirdness...
>
> Hmm I thought OEMs who ship stuff that are based on Chrome OS would have to do
> the final tuning here, which would be based on the recommendation of the SoC
> vendor. And I'm being overly generic here to think not only SoC from Intel
> which traditionally they have been treated in different ways.
>
> I think you provide a generic stack for OEMs, no?

No, that's the Android way.  The only way Chrome OS can ship updates
for the whole fleet every ~6 weeks and support it for so many years is
that all the builds and updates happen on Google servers.  The only
way Google can maintain this is to not have a separate kernel code
base for every single variant of every single board.


> Generally for RT tasks, Linux always required an admin to do the tuning. And to
> provide an automatic solution that fits all is not easy to happen, because what
> ultimately is important for userspace, is only known by the userspace.
>
> This is an interesting problem for me personally that I have been trying to
> look at in my free time. On general purpose systems, it's hard to reason about
> what's important because, as you say, you distribute something that should
> target a wide range of platforms. And sometimes the end user (like a person
> installing Ubuntu Desktop on their laptop), have no clue what a driver is even
> to pick the right tuning for all RT tasks in their system.
>
> But this problem already exists and catching up with this will need more work
> from both distros and maybe kernel. I can't see a possible situation where the
> kernel can do all the tuning without userspace providing more info anyway.
>
> The per-device weirdness you're talking about is just how the way goes in
> a world where there are many SoCs that are created to target different budgets
> and use cases.

I think it's sane for the OS to do very high level tuning, like "this
platform has an underpowered CPU and being fast is more important than
battery life, so error on the side of running fast" or "this platform
has a fast SSD so tune disk algorithms appropriately".  ...but picking
specific values gets tricky.


> So I don't see the 2 worlds (laptops/mobile) really different, they just
> traditionally started differently where such variations in SoC didn't exist
> that much. But there are more Arm based SoCs that are targetting laptop markets
> now.. So you never know when they will be dealing with the same variations the
> mobile world sees today.

The slowest laptop we currently support is a Quad-core A17 running at
~1.8 GHz.  On that CPU the cros_ec thread needs to be realtime (so it
doesn't get interrupted) but doesn't need any particular CPU speed.

That being said, that does remind me that on that laptop we did give
up and end up with a hack to set a minimum CPU speed when USB audio
was happening.  That CPU has dwc2 for its USB controller and it's
utterly important to service interrupts in < 125 us when USB audio is
going on.  So in that case, yes, I was forced to do tuning and pick a
specific value.


> > > People tend to think of the flagship SoCs which are powerful, but if you
> > > consider the low and medium end devices there's a massive spectrum over there
> > > that this range is trying to cover.
> >
> > Yeah, perhaps you're right.  When thinking about a laptop it's almost
> > always a fairly powerful device and things could certainly be
> > different for very low end chips trying to run Linux.
>
> I think there are low end laptops in the market that barely have enough grunt
> to do work. So not all laptops are fairly powerful.
>
> >
> >
> > > I would expect older boards init script to be separate for newer boards init
> > > script. The OS by default boosts all RT tasks unless a platform specific script
> > > overrides that. So I can't see how an OS upgrade would affect older boards.
> >
> > In the Chrome OS world I'm part of, the people supporting the boards
> > are not always the people adding new whizbang features.  We get new
> > versions of the OS every 6 weeks and those new versions may change the
> > way things work pretty significantly.  We ship those new versions off
> > to all boards.  Certainly they undergo testing, but there are a lot of
> > boards and if something is not tuned as well as it was when the device
> > first shipped it's likely nobody will really notice.  This is my bias
> > against needing per-board tuning.
>
> Apologies for my lack knowledge about the exact process in Chrome OS. In my
> head, I think what you do is like what Android and other distros do. Provide
> a software stack that can be used on any platform. On Android OEMs do have to
> do the tuning (with a help from SoC vendor usually). Not many laptops ship with
> Linux as their default OS, but this is an increasing trend and LWN did write
> something recently about the demand is increasing for Linux based laptops.
>
>
> I thought Chrome OS is the same, where an OEM will take your deliverables and
> do the final integration.
>
> So I agree at your level it might be hard to reason about the full spectrum.
> But I thought the OEMs that wants to ship Chrome OS will need to look at init
> scripts, drivers etc to ensure their laptop is competitive.
>
> >
> >
> > > This knob still allows you to disable the max boosting and use the per-task
> > > uclamp interface to boost only those tasks you care about. AFAIK this is
> > > already done in a hacky way in android devices via special vendors provisions.
> >
> > Yeah.  I don't think I have enough skin in the game to really say one
> > way or the other what the API should be so I'll probably stay off the
> > other, bigger thread and let others decide what the best API should
> > be.  For Chrome OS I'd probably advocate just disabling the default
> > boost but even there I'd be willing to defer to the folks doing the
> > actual work.
>
> Yes I appreciate the challenges you have. I think for most users disabling is
> good enough for them as RT tasks could end up causing a lot of power to be
> wasted unnecessarily. But if someone wants to take the extra mile and squeeze
> the best compromise, they can :)

Yeah, thinking about the USB audio hack we ended up with makes me
understand that sometimes on lower-end systems you are forced to do
tuning even if it's annoying.

-Doug