From: Darren Hart <dvhart@infradead.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
Jean Delvare <jdelvare@suse.de>,
Andy Shevchenko <andy@infradead.org>,
platform-driver-x86@vger.kernel.org,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Subject: Re: intel_turbo_max_3 non-modularity
Date: Fri, 28 Apr 2017 15:51:53 -0700 [thread overview]
Message-ID: <20170428225153.GB32336@fury> (raw)
In-Reply-To: <20170428213434.lljyvywigcguupjm@hirez.programming.kicks-ass.net>
On Fri, Apr 28, 2017 at 11:34:34PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 28, 2017 at 01:49:49PM -0700, Darren Hart wrote:
> > > > Non-modular drivers do not scale. This is a serious issue considering
> > > > the growth rate of the kernel.
> > >
> > > Again, this is an oversimplification that doesn't reflect reality.
> > > There are many valid reasons why some drivers be built-in only. The
> > > whole world isn't a distro looking to say "=m" to every config option
> > > simply because they don't have the time or resources to actually triage
> > > them all and see what is relevant for their use case(es).
> > >
> >
> > The point is valid though, and something we need to be keeping an eye on,
> > especially with all the non-architectural SoC feature drivers we're seeing code
> > roll in for. I appreciate you raising the concern Jean.
>
> FWIW:
>
> There's things like ACPI-Processor-Idle and intel_idle that need to be
> built-in for correctness sake.
>
> They can mark the TSC unstable, and this should be done before we run
> userspace, which with unstable TSC could see wobbly time before we kill
> the TSC.
>
> This is a somewhat non-obvious case, and on the face of it those could
> be modular drivers. But building them as modules gets them loaded far
> too late if ever.
>
> These are subtle things and easily overlooked.
Thanks Peter, I will be sure to do my due diligence in determining why something
may be bool before applying incoming patches to change that. This isn't clearly
documented in intel_idle for example, but it is at least explicitly described in
the git log for the Kconfig.
--
Darren Hart
VMware Open Source Technology Center
prev parent reply other threads:[~2017-04-28 22:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-24 9:31 intel_turbo_max_3 non-modularity Jean Delvare
2017-04-24 14:02 ` Paul Gortmaker
2017-04-27 21:48 ` Darren Hart
2017-04-27 23:18 ` Srinivas Pandruvada
2017-04-28 7:55 ` Peter Zijlstra
2017-04-28 13:20 ` Jean Delvare
2017-04-28 13:46 ` Peter Zijlstra
2017-04-28 15:49 ` Darren Hart
2017-04-28 16:34 ` Peter Zijlstra
2017-04-28 20:58 ` Darren Hart
2017-04-28 21:39 ` Peter Zijlstra
2017-04-28 8:40 ` Jean Delvare
2017-04-28 20:35 ` Srinivas Pandruvada
2017-04-28 7:49 ` Jean Delvare
2017-04-28 17:44 ` Paul Gortmaker
2017-04-28 20:49 ` Darren Hart
2017-04-28 21:34 ` Peter Zijlstra
2017-04-28 22:51 ` Darren Hart [this message]
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=20170428225153.GB32336@fury \
--to=dvhart@infradead.org \
--cc=andy@infradead.org \
--cc=jdelvare@suse.de \
--cc=paul.gortmaker@windriver.com \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
/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