linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Brown, Len" <len.brown@intel.com>
To: "rcochran@linutronix.de" <rcochran@linutronix.de>
Cc: "Gortmaker, Paul (Wind River)" <paul.gortmaker@windriver.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Len Brown <lenb@kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: RE: [PATCH] drivers/idle: make intel_idle.c driver more explicitly non-modular
Date: Tue, 5 Apr 2016 05:53:47 +0000	[thread overview]
Message-ID: <1A7043D5F58CCB44A599DFD55ED4C94846A1CD40@fmsmsx115.amr.corp.intel.com> (raw)
In-Reply-To: <20160405043017.GA24357@linutronix.de>



> -----Original Message-----
> From: rcochran@linutronix.de [mailto:rcochran@linutronix.de]
> Sent: Tuesday, April 05, 2016 12:30 AM
> To: Brown, Len
> Cc: Gortmaker, Paul (Wind River); linux-kernel@vger.kernel.org; Len Brown;
> linux-pm@vger.kernel.org
> Subject: Re: [PATCH] drivers/idle: make intel_idle.c driver more
> explicitly non-modular
> 
> On Tue, Apr 05, 2016 at 04:20:47AM +0000, Brown, Len wrote:
> > The first idle driver to register with cpuidle wins.
> >
> > intel_idle should always get the opportunity
> > to probe and register before acpi_idle (processor_idle.c)
> >
> > When intel_idle was allowed to be modular,
> > some distros build their kernel and loaded modules
> > such that acpi_idle could probe first.  In such
> > a kernel, intel_idle became dead code.
> >
> > As intel_idle is a small driver, the q	uick fix
> > was to make it Y/N so that it would always probe
> > before acpi_idle, no matter how acpi_idle
> > is build and loaded.
> >
> > Yes, even though intel_idle is a tiny driver, I think
> > it would be good to be able to unload it when it doesn't probe.
> 
> And that means fixing the race with acpi_idle, right?
> 
> > Today, it appears that acpi_idle (acpi/processor_idle.c)
> > is compiled Y/N.
> 
> So it, too, needs work?

"needs" is somewhat subjective.
Some may argue that this driver is so small,
that an effort to save memory might be more effectively
directed elsewhere.  But if the goal is to save the memory
consumed by this driver when the driver doesn't probe,
then yes, it would have to be made modular.

I don't remember what ACPI dependency made it non-modular.
ACPI has some tricky initialization ordering issues
that are BIOS dependent, and sometimes out of our control.

> > No, I do not believe that cpuidle should bother
> > supporting changing idle drivers at run-time.
> 
> Huh?  But you just said, "it would be good to be able to unload it
> when it doesn't probe."

being able to switch the registered driver at run-time
does not require the driver to be modular.

cheers,
-Len

  reply	other threads:[~2016-04-05  5:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-27 17:29 [PATCH] drivers/idle: make intel_idle.c driver more explicitly non-modular Paul Gortmaker
2016-04-04 19:55 ` Paul Gortmaker
2016-04-05  3:11   ` rcochran
2016-04-05  4:20     ` Brown, Len
2016-04-05  4:30       ` rcochran
2016-04-05  5:53         ` Brown, Len [this message]
2016-04-05  7:33           ` rcochran
2016-04-07 16:53             ` Daniel Lezcano
2016-04-20 15:25               ` [PATCH v2] " Paul Gortmaker
2016-04-20 18:13                 ` Daniel Lezcano
2016-04-21  3:12                   ` Paul Gortmaker
2016-04-21  8:04                     ` Daniel Lezcano
2016-04-21 12:44                       ` Paul Gortmaker
2016-04-21 13:21                         ` Daniel Lezcano
2016-04-21 17:42                           ` Paul Gortmaker
2016-06-16  5:00                             ` Len Brown
2016-04-05 18:22     ` [PATCH] " Paul Gortmaker

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=1A7043D5F58CCB44A599DFD55ED4C94846A1CD40@fmsmsx115.amr.corp.intel.com \
    --to=len.brown@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=rcochran@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).