From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ak@linux.intel.com>
Received: from mga14.intel.com ([192.55.52.115])
	by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
	(Exim 4.80)
	(envelope-from <ak@linux.intel.com>)
	id 1fR1do-00040V-31
	for speck@linutronix.de; Thu, 07 Jun 2018 22:36:16 +0200
Date: Thu, 7 Jun 2018 13:36:13 -0700
From: Andi Kleen <ak@linux.intel.com>
Subject: [MODERATED] Re: [patch V2 00/12] cpu/hotplug: SMT control
Message-ID: <20180607203613.GF7220@tassilo.jf.intel.com>
References: <20180606192714.754943543@linutronix.de>
 <20180606231622.GD7220@tassilo.jf.intel.com>
 <alpine.DEB.2.21.1806070833590.1580@nanos.tec.linutronix.de>
 <nycvar.YFH.7.76.1806070939080.6203@cbobk.fhfr.pm>
MIME-Version: 1.0
In-Reply-To: <nycvar.YFH.7.76.1806070939080.6203@cbobk.fhfr.pm>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: speck@linutronix.de
List-ID: <speck.linutronix.de>

On Thu, Jun 07, 2018 at 09:42:35AM +0200, speck for Jiri Kosina wrote:
> On Thu, 7 Jun 2018, speck for Thomas Gleixner wrote:
> 
> > > I still think it's pointless to add so much kernel code for something
> > > that can be done with a straight forward user script at run time
> > > using existing APIs.
> > > 
> > > We need strong justifications to add new kernel APIs.
> > > 
> > > https://raw.githubusercontent.com/andikleen/pmu-tools/master/cputop.py
> > 
> > It can be done with 3 lines of bash as well.
> > 
> > But it does neither work from the kernel command line nor does it provide
> > protections against re-online nor full enforcement. 
> > 
> > Sure it adds the massive amount of 225 lines including comments and
> > Documentation, but it's straight forward and works and has it's merits as a
> > conveniance/testing mechanism as well.
> 
> In addition to that, form a purely distro-centric POV: how exactly would 
> you envision this script to be shipped to the world (as we'll have to have 
> way to distribute it reliably to all the 'untrusted VM' providers at 
> least). Creating a separate 'smt-disable' package just for this seems like 
> an overkill, OTOH everybody has a process in place how to tweak kernel 
> cmdline / sysfs parameters.

I would add the script to tools/*

It could be added to one of the existing packages that package software
from there, and then you recommend those who actually run untrusted
VMs to use it. Most likely it's more complicated than just tweaking
the command line anyways, because likely you only want it on a subset
of the cores

I spent some time now rewriting my script to C as a "smtctl" and it could be
easily packaged in tools/*

-Andi