[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0g2sCth5nofpPt4ucjQC0W=aU3YmSPqSRp+OyFWgS6YxA@mail.gmail.com>
Date: Fri, 25 Sep 2020 17:24:03 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Peter Zijlstra <peterz@...radead.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Borislav Petkov <bp@...en8.de>,
"the arch/x86 maintainers" <x86@...nel.org>,
Tony Luck <tony.luck@...el.com>, Len Brown <lenb@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux PM <linux-pm@...r.kernel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Naresh Kamboju <naresh.kamboju@...aro.org>
Subject: Re: [RFC][PATCH 4/4] acpi: Take over RCU-idle for C3-BM idle
On Fri, Sep 25, 2020 at 5:20 PM Guenter Roeck <linux@...ck-us.net> wrote:
>
> On Tue, Sep 15, 2020 at 12:32:01PM +0200, Peter Zijlstra wrote:
> > The C3 BusMaster idle code takes lock in a number of places, some deep
> > inside the ACPI code. Instead of wrapping it all in RCU_NONIDLE, have
> > the driver take over RCU-idle duty and avoid flipping RCU state back
> > and forth a lot.
> >
> > ( by marking 'C3 && bm_check' as RCU_IDLE, we _must_ call enter_bm() for
> > that combination, otherwise we'll loose RCU-idle, this requires
> > shuffling some code around )
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>
> ia64:defconfig:
>
> ERROR: modpost: "rcu_idle_enter" [drivers/acpi/processor.ko] undefined!
> ERROR: modpost: "rcu_idle_exit" [drivers/acpi/processor.ko] undefined!
>
> I realize that this has already been reported more than a week ago, with
> no visible reaction. Another problem introduced in the same file, resulting
> in
>
> drivers/acpi/processor_idle.c: In function 'lapic_timer_needs_broadcast':
> drivers/acpi/processor_idle.c:179:1: warning:
> no return statement in function returning non-void
>
> may cause ia64 boot problems since a non-zero return value will trigger
> a function call. AFAICS that is not supposed to happen on ia64.
There are fixes for the above in my tree, they will go to Linus shortly.
Thanks!
Powered by blists - more mailing lists