linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
	npiggin@suse.de, linux-arch@vger.kernel.org, mingo@elte.hu,
	paulmck@linux.vnet.ibm.com
Subject: Re: [PATCH 1/10] Add generic helpers for arch IPI function calls
Date: Sun, 06 Jul 2008 10:21:18 -0700	[thread overview]
Message-ID: <4870FF0E.80200@goop.org> (raw)
In-Reply-To: <1212051504-12561-2-git-send-email-jens.axboe@oracle.com>

Jens Axboe wrote:
> +/**
> + * __smp_call_function_single(): Run a function on another CPU
> + * @cpu: The CPU to run on.
> + * @data: Pre-allocated and setup data structure
> + *
> + * Like smp_call_function_single(), but allow caller to pass in a pre-allocated
> + * data structure. Useful for embedding @data inside other structures, for
> + * instance.
> + *
> + */
> +void __smp_call_function_single(int cpu, struct call_single_data *data)
>   

Does this have any users?  Proposed users?

> +{
> +	/* Can deadlock when called with interrupts disabled */
> +	WARN_ON((data->flags & CSD_FLAG_WAIT) && irqs_disabled());
>   

Can it be reasonably be used without FLAG_WAIT set?  If it doesn't have 
FLAG_WAIT, it must have FLAG_ALLOC set, but it can't have FLAG_ALLOC if 
the csd structure is embedded in something else.

> +
> +	generic_exec_single(cpu, data);
> +}
> +
> +/**
> + * smp_call_function_mask(): Run a function on a set of other CPUs.
> + * @mask: The set of cpus to run on.
> + * @func: The function to run. This must be fast and non-blocking.
> + * @info: An arbitrary pointer to pass to the function.
> + * @wait: If true, wait (atomically) until function has completed on other CPUs.
> + *
> + * Returns 0 on success, else a negative status code.
> + *
> + * If @wait is true, then returns once @func has returned.
> + *
> + * You must not call this function with disabled interrupts or from a
> + * hardware interrupt handler or from a bottom half handler.
> + */
> +int smp_call_function_mask(cpumask_t mask, void (*func)(void *), void *info,
> +			   int wait)
> +{
> +	struct call_function_data d;
> +	struct call_function_data *data = NULL;
> +	cpumask_t allbutself;
> +	unsigned long flags;
> +	int cpu, num_cpus;
> +
> +	/* Can deadlock when called with interrupts disabled */
> +	WARN_ON(irqs_disabled());
> +
> +	cpu = smp_processor_id();
>   

What prevents us from changing cpus?  Are all callers supposed to 
disable preemption?  If so, should we WARN for it?

> +	allbutself = cpu_online_map;
> +	cpu_clear(cpu, allbutself);
> +	cpus_and(mask, mask, allbutself);
> +	num_cpus = cpus_weight(mask);
>   

Ditto: What prevents the online map changing under our feet?  Is 
disabling preemption enough?

> +
> +	/*
> +	 * If zero CPUs, return. If just a single CPU, turn this request
> +	 * into a targetted single call instead since it's faster.
> +	 */
> +	if (!num_cpus)
> +		return 0;
> +	else if (num_cpus == 1) {
> +		cpu = first_cpu(mask);
> +		return smp_call_function_single(cpu, func, info, 0, wait);
> +	}
>   

It's weirdly inconsistent that smp_call_function_mask will ignore the 
current cpu if its in the mask, but smp_call_function_single will call 
the function locally if the specified cpu is the current one.  I know 
this is a hold-over from the old code, but could we finally fix it now?  
I guess it's still reasonable for smp_call_function to call on 
everywhere but current cpu, but it can do its own mask manipulation to 
sort that out.

> +
> +	if (!wait) {
> +		data = kmalloc(sizeof(*data), GFP_ATOMIC);
> +		if (data)
> +			data->csd.flags = CSD_FLAG_ALLOC;
> +	}
> +	if (!data) {
> +		data = &d;
> +		data->csd.flags = CSD_FLAG_WAIT;
> +	}
> +
> +	spin_lock_init(&data->lock);
> +	data->csd.func = func;
> +	data->csd.info = info;
> +	data->refs = num_cpus;
> +
> +	/*
> +	 * need to see above stores before the cpumask is valid for the CPU
> +	 */
> +	smp_wmb();
> +	data->cpumask = mask;
> +
> +	spin_lock_irqsave(&call_function_lock, flags);
> +	list_add_tail_rcu(&data->csd.list, &call_function_queue);
> +	spin_unlock_irqrestore(&call_function_lock, flags);
> +
> +	/* Send a message to all CPUs in the map */
> +	arch_send_call_function_ipi(mask);
> +
> +	/* optionally wait for the CPUs to complete */
> +	if (wait)
>   
Should this test for data->csd.flags & CDS_FLAG_WAIT?  Or should the "if 
(!data)" path above also set "wait"?

> +		csd_flag_wait(&data->csd);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(smp_call_function_mask);
> +
> +/**
> + * smp_call_function(): Run a function on all other CPUs.
> + * @func: The function to run. This must be fast and non-blocking.
> + * @info: An arbitrary pointer to pass to the function.
> + * @natomic: Unused
> + * @wait: If true, wait (atomically) until function has completed on other CPUs.
> + *
> + * Returns 0 on success, else a negative status code.
> + *
> + * If @wait is true, then returns once @func has returned; otherwise
> + * it returns just before the target cpu calls @func.
> + *
> + * You must not call this function with disabled interrupts or from a
> + * hardware interrupt handler or from a bottom half handler.
> + */
> +int smp_call_function(void (*func)(void *), void *info, int natomic, int wait)
> +{
> +	int ret;
> +
> +	preempt_disable();
> +	ret = smp_call_function_mask(cpu_online_map, func, info, wait);
> +	preempt_enable();
> +	return ret;
> +}
> +EXPORT_SYMBOL(smp_call_function);
>   

  parent reply	other threads:[~2008-07-06 17:21 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-29  8:58 [PATCH 0/10] Add generic helpers for arch IPI function calls #4 Jens Axboe
2008-05-29  8:58 ` [PATCH 1/10] Add generic helpers for arch IPI function calls Jens Axboe
2008-05-30 11:24   ` Paul E. McKenney
2008-06-06  8:44     ` Jens Axboe
2008-06-10 14:51   ` Catalin Marinas
2008-06-10 15:44     ` James Bottomley
2008-06-10 16:04       ` Catalin Marinas
2008-06-10 15:47     ` Paul E. McKenney
2008-06-10 16:53       ` Catalin Marinas
2008-06-11  3:25         ` Nick Piggin
2008-06-11 10:13           ` Catalin Marinas
2008-06-11 10:13             ` Catalin Marinas
2008-07-06 17:21   ` Jeremy Fitzhardinge [this message]
2008-05-29  8:58 ` [PATCH 2/10] x86: convert to generic helpers for " Jens Axboe
2008-05-29 12:12   ` Jeremy Fitzhardinge
2008-05-29 12:17     ` Jens Axboe
2008-05-29 13:47       ` Jeremy Fitzhardinge
2008-05-29  8:58 ` [PATCH 3/10] powerpc: " Jens Axboe
2008-05-29  8:58 ` [PATCH 4/10] ia64: " Jens Axboe
2008-05-29  8:58 ` [PATCH 5/10] alpha: " Jens Axboe
2008-05-29  8:58 ` [PATCH 6/10] arm: " Jens Axboe
2008-06-02 12:29   ` Russell King
2008-06-02 12:29     ` Russell King
2008-06-06  8:47     ` Jens Axboe
2008-05-29  8:58 ` [PATCH 7/10] m32r: " Jens Axboe
2008-05-29  8:58 ` [PATCH 8/10] mips: " Jens Axboe
2008-05-29 14:20   ` Ralf Baechle
2008-05-30  7:23     ` Jens Axboe
2008-05-29  8:58 ` [PATCH 9/10] parisc: " Jens Axboe
2008-05-31  7:00   ` Kyle McMartin
2008-05-31  7:00     ` Kyle McMartin
2008-06-02  8:17     ` Jens Axboe
2008-06-02 16:09       ` Kyle McMartin
2008-06-06  8:47         ` Jens Axboe
2008-06-06 21:11           ` Kyle McMartin
2008-06-09  8:47             ` Jens Axboe
2008-05-29  8:58 ` [PATCH 10/10] sh: " Jens Axboe
2008-06-01  8:57 ` [PATCH 0/10] Add generic helpers for arch IPI function calls #4 Andrew Morton
2008-06-01  8:57   ` Andrew Morton
2008-06-01  9:52   ` Jeremy Fitzhardinge
  -- strict thread matches above, loose matches on Subject: below --
2008-04-29  7:26 [PATCH 0/10] Add generic helpers for arch IPI function calls #3 Jens Axboe
     [not found] ` <1209453990-7735-1-git-send-email-jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2008-04-29  7:26   ` [PATCH 1/10] Add generic helpers for arch IPI function calls Jens Axboe
2008-04-29  7:26     ` Jens Axboe
     [not found]     ` <1209453990-7735-2-git-send-email-jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2008-04-29 13:59       ` Paul E. McKenney
2008-04-29 13:59         ` Paul E. McKenney
     [not found]         ` <20080429135936.GC12390-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2008-04-30 11:29           ` Paul E. McKenney
2008-04-30 11:29             ` Paul E. McKenney
     [not found]             ` <20080430112934.GA23203-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2008-04-30 11:34               ` Jens Axboe
2008-04-30 11:34                 ` Jens Axboe
     [not found]                 ` <20080430113456.GY12774-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
2008-04-30 12:17                   ` Paul E. McKenney
2008-04-30 12:17                     ` Paul E. McKenney
     [not found]                     ` <20080430121712.GR11126-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2008-04-30 12:37                       ` Jens Axboe
2008-04-30 12:37                         ` Jens Axboe
     [not found]                         ` <20080430123717.GC12774-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
2008-05-01  2:44                           ` Paul E. McKenney
2008-05-01  2:44                             ` Paul E. McKenney
2008-05-02  2:02                         ` Paul E. McKenney
2008-05-02  2:12                           ` Nick Piggin
2008-05-02 12:29                             ` Paul E. McKenney
2008-05-02 12:42                               ` Paul E. McKenney
2008-05-02 12:59                                 ` Peter Zijlstra
2008-05-02 12:59                                   ` Peter Zijlstra
2008-05-02 14:21                                   ` Paul E. McKenney
2008-05-02 14:21                                     ` Paul E. McKenney
2008-05-03  2:30                                     ` Paul E. McKenney
2008-05-03  5:49                                   ` Nick Piggin
2008-05-03 18:11                                     ` Paul E. McKenney
2008-05-04 22:04                                       ` Paul E. McKenney
2008-05-05  4:15                                       ` Nick Piggin
2008-05-05  4:15                                         ` Nick Piggin
2008-05-05 17:43                                         ` Paul E. McKenney
2008-05-07 20:42                                           ` Jens Axboe
2008-05-08  4:36                                             ` Paul E. McKenney
2008-05-02 12:50                               ` Keith Owens
2008-05-02 13:09                                 ` Paul E. McKenney
2008-04-30 22:56       ` Jeremy Fitzhardinge
2008-04-30 22:56         ` Jeremy Fitzhardinge

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=4870FF0E.80200@goop.org \
    --to=jeremy@goop.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    /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).