linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Chris Friesen <chris.friesen@windriver.com>
Cc: linux-kernel@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Vu Tran <vu.tran@windriver.com>,
	Jim Somerville <Jim.Somerville@windriver.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] affine kernel threads to specified cpumask
Date: Tue, 24 Mar 2020 12:07:07 -0300	[thread overview]
Message-ID: <20200324150707.GB24352@fuller.cnet> (raw)
In-Reply-To: <e76aedad-8c55-1651-007d-6e17882403cb@windriver.com>

Hi Chris,

On Mon, Mar 23, 2020 at 09:29:23AM -0600, Chris Friesen wrote:
> On 3/23/2020 7:54 AM, Marcelo Tosatti wrote:
> > 
> > This is a kernel enhancement to configure the cpu affinity of kernel
> > threads via kernel boot option kthread_cpus=<cpulist>.
> > 
> > With kthread_cpus specified, the cpumask is immediately applied upon
> > thread launch. This does not affect kernel threads that specify cpu
> > and node.
> > 
> > This allows CPU isolation (that is not allowing certain threads
> > to execute on certain CPUs) without using the isolcpus= parameter,
> > making it possible to enable load balancing on such CPUs
> > during runtime.
> > 
> > Note-1: this is based off on MontaVista's patch at
> > https://github.com/starlingx-staging/stx-integ/blob/master/kernel/kernel-std/centos/patches/affine-compute-kernel-threads.patch
> 
> It's Wind River, not MontaVista. :)

Doh.

> > Difference being that this patch is limited to modifying
> > kernel thread cpumask: Behaviour of other threads can
> > be controlled via cgroups or sched_setaffinity.
> 
> What cgroup would the usermode helpers called by the kernel end up in?
> Same as init?
> 
> Assuming that's covered, I'm good with this patch.
> 
> <snip>

 * Runs a user-space application.  The application is started
 * asynchronously if wait is not set, and runs as a child of system workqueues.
 * (ie. it runs with full root capabilities and optimized affinity).
 */
int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
{
	...
        queue_work(system_unbound_wq, &sub_info->work);


And unbound workqueue workers cpumask are controllable:

static void worker_attach_to_pool(struct worker *worker,
                                   struct worker_pool *pool)
{
        mutex_lock(&wq_pool_attach_mutex);

        /*
         * set_cpus_allowed_ptr() will fail if the cpumask doesn't have any
         * online CPUs.  It'll be re-applied when any of the CPUs come up.
         */
        set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask);

> 
> > +static struct cpumask user_cpu_kthread_mask __read_mostly;
> > +static int user_cpu_kthread_mask_valid __read_mostly;
> 
> Would it be cleaner to get rid of user_cpu_kthread_mask_valid and just
> move the "if (!cpumask_empty" check into init_kthread_cpumask()?  I'm
> not really opinionated, just thinking out loud.

Will get rid of this with Thomas's isolcpus= suggestion.

> > +int __init init_kthread_cpumask(void)
> > +{
> > +	if (user_cpu_kthread_mask_valid == 1)
> > +		cpumask_copy(&__cpu_kthread_mask, &user_cpu_kthread_mask);
> > +	else
> > +		cpumask_copy(&__cpu_kthread_mask, cpu_all_mask);
> > +
> > +	return 0;
> > +}
> > +
> > +static int __init kthread_setup(char *str)
> > +{
> > +	cpulist_parse(str, &user_cpu_kthread_mask);
> > +	if (!cpumask_empty(&user_cpu_kthread_mask))
> > +		user_cpu_kthread_mask_valid = 1;
> > +
> > +	return 1;
> > +}


  reply	other threads:[~2020-03-24 15:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23 13:54 [PATCH] affine kernel threads to specified cpumask Marcelo Tosatti
2020-03-23 15:29 ` Chris Friesen
2020-03-24 15:07   ` Marcelo Tosatti [this message]
2020-03-23 16:22 ` Thomas Gleixner
2020-03-23 17:02   ` Chris Friesen
2020-03-23 20:31     ` Thomas Gleixner
2020-03-24 11:38       ` Marcelo Tosatti
2020-03-24 15:20       ` [PATCH v2] isolcpus: " Marcelo Tosatti
2020-03-24 15:56         ` Chris Friesen
2020-03-24 16:50           ` Marcelo Tosatti
2020-03-25  0:30         ` Frederic Weisbecker
2020-03-25 11:47           ` Marcelo Tosatti
2020-03-26 16:20             ` Frederic Weisbecker
2020-03-26 16:52               ` Frederic Weisbecker
2020-03-27 12:07               ` Marcelo Tosatti
2020-03-25 18:05         ` David Laight
2020-03-26 11:28           ` Marcelo Tosatti
2020-03-26 16:22           ` Frederic Weisbecker
2020-03-26 16:32             ` Chris Friesen
2020-03-26 16:51               ` Frederic Weisbecker

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=20200324150707.GB24352@fuller.cnet \
    --to=mtosatti@redhat.com \
    --cc=Jim.Somerville@windriver.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris.friesen@windriver.com \
    --cc=cl@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vu.tran@windriver.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;
as well as URLs for NNTP newsgroup(s).