All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Darren Hart <dvhart@infradead.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Andy Shevchenko <andy@infradead.org>,
	platform-driver-x86@vger.kernel.org
Subject: Re: intel_turbo_max_3 non-modularity
Date: Fri, 28 Apr 2017 15:20:21 +0200	[thread overview]
Message-ID: <20170428152021.51d3b9c5@endymion> (raw)
In-Reply-To: <20170428075514.dmywqqe5lpad67w5@hirez.programming.kicks-ass.net>

Hi Peter,

On Fri, 28 Apr 2017 09:55:14 +0200, Peter Zijlstra wrote:
> On Thu, Apr 27, 2017 at 04:18:46PM -0700, Srinivas Pandruvada wrote:
> 
> > Before to this patch, only intel_pstate driver called these two
> > sched_xx() functions. intel_pstate can be only be built-in, so no
> > effort was made to export these functions when they were developed to
> > add ITMT support.
> > But turbo_max_3 driver driver will only load on a subset of non HWP
> > Broadwell systems, making module is not a bad idea. To do that we can
> > export these two sched_xx() functions as they are only related to ITMT
> > function anyway.
> > If Peter agrees, I can send a patch to change this.
> 
> I would really hate to expose sched_set_itmt_core_prio() to modules. Too
> much potential for trainwrecks.

These functions are already available. Not exporting them only forces
users to be built-in. This doesn't prevent anything, and in practice
makes things worse.

I don't really buy the argument of not letting legitimate users access
something they need in the name of preventing hypothetical abusers from
breaking things. If that ever happens, they will get the pain they
deserve. How do you care? If you want to put any limitations on what
people should be using these functions for, let's just document it?

> Also, this driver is dinky, making it a modules doesn't save anything
> much,

Not buying this either, sorry. Yes, size is one thing to consider for
such decisions, but that's only one factor. Amongst other factors is
how many users need the code in question. With:

static const struct x86_cpu_id itmt_legacy_cpu_ids[] = {
	ICPU(INTEL_FAM6_BROADWELL_X),
	{}
};
MODULE_DEVICE_TABLE(x86cpu, itmt_legacy_cpu_ids);

and

	if (boot_cpu_has(X86_FEATURE_HWP))
		return -ENODEV;

it is pretty clear to me that the share of users that will need this
driver is fairly limited.

If you would only consider the code size then there are several hundreds
of in-tree device drivers that shouldn't be modularized either, as they
are the same size or less. But you have to think globally, not
per-driver. Generic distribution kernels can only fly as long as all
hardware-specific code can be modularized.

-- 
Jean Delvare
SUSE L3 Support

  reply	other threads:[~2017-04-28 13:20 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 [this message]
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

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=20170428152021.51d3b9c5@endymion \
    --to=jdelvare@suse.de \
    --cc=andy@infradead.org \
    --cc=dvhart@infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.