All of lore.kernel.org
 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: 68+ 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-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-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-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  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 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 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 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.