[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPYmKFsJu8fswWD1da6Bj=GrdNvjnsyF9434e9NNP=4PKz5t6A@mail.gmail.com>
Date: Thu, 26 Sep 2024 15:55:16 +0800
From: Xu Lu <luxu.kernel@...edance.com>
To: Guo Ren <guoren@...nel.org>
Cc: paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
andy.chiu@...ive.com, christoph.muellner@...ll.eu, ajones@...tanamicro.com,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
lihangjing@...edance.com, dengliang.1214@...edance.com,
xieyongji@...edance.com, chaiwen.cc@...edance.com
Subject: Re: [External] Re: [PATCH v3 1/2] riscv: process: Introduce idle
thread using Zawrs extension
Hi Guo Ren,
> The hardware implementations of "WFI & WRS" are different.
> - The WFI could enter a more profound power consumption-saving needed
> to keep IRQ alive, but the WRS doesn't.
> - WRS is designed for cond_load, which needs to keep cache coherency alive.
>
> So, we couldn't simply & statically use an extension check to choose
> WRS or WFI for idle.
Great comment.
I think maintaining cache coherence is not a big power problem for
WRS. In a naive implementation, the wrs instruction only needs to
maintain a valid cache line in L1 and wake up when other cpu wants to
make it invalid. This behavior won't incur too much power consumption.
And there does exist a power consumption gap if some vendors implement
WFI instruction to flush and power down the entire L1/L2 cache (for
example, provide CPUPWRCTLR register to control WFI behavior like
ARM), while WRS can not do the same thing. Whether WFI will power down
cache is not mentioned in RISC-V spec and is somehow vendor-customized
(Please remind me if I missed anything). So it is hard to use a
unified method to detect or control the cache power down behavior of
WFI instruction. And that is why we provide a CONFIG to let the user
choose whether to enable WRS IDLE or not.
>
> > +}
> > +
> > int set_unalign_ctl(struct task_struct *tsk, unsigned int val)
> > {
> > if (!unaligned_ctl_available())
> > --
> > 2.20.1
> >
>
>
> --
> Best Regards
> Guo Ren
Best Regards,
Xu Lu
Powered by blists - more mailing lists