All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: rusty@rustcorp.com.au, jens.axboe@oracle.com, schwidefsky@de.ibm.com
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH/RFC 0/4] Add stop_machine_get/put_threads to stop_machine infrastructrue.
Date: Fri, 03 Oct 2008 12:56:32 +0200	[thread overview]
Message-ID: <20081003105632.357231142@de.ibm.com> (raw)

This patch series would allow to convert s390 to the generic IPI interface.
We can't to that currently since our etr/stp code relies on the old semantics
of smp_call_function that guarantee that the function only returns after all
receiving cpus have acknowledged the IPI. That way it is known that all other
cpus are running in an interrupt handler with interrupts disabled.
This is not true anymore with the generic IPI infrastructure.

So one idea was to use stop_machine in order to synchronize all cpus. Rusty
was kind enough to extend it so that it is now possible to run a function
on several cpus, instead of just one.
However we need to be able to do that without allocating any memory. That's
what this patch set is about. It introduces two new interfaces which allow
to create the kstop threads in advance so that a subsequent stop_machine call
will be able to run without the need to create any threads and therefore
avoids the need to allocate any memory.

The two interfaces (see patch 2) are:

stop_machine_get_threads() - create all needed kstop threads in advance.
If it is called multiple times it will just increase an internal usecount.

stop_machine_put_threads() - kill all previously created kstop threads,
if the internal usecount drops to zero.

Patch 1 is a stop_machine bugfix and is independent of the rest
Patch 2 introduces the new proposed interface
Patch 3 converts the s390 etr and stp code to the new API
Patch 4 converts s390 to the generic IPI interface

Thanks,
Heiko

             reply	other threads:[~2008-10-03 10:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-03 10:56 Heiko Carstens [this message]
2008-10-03 10:56 ` [PATCH/RFC 1/4] stop_machine: atomic update for combined return value Heiko Carstens
2008-10-03 10:56 ` [PATCH/RFC 2/4] stop_machine: add stop_machine_get/put_threads interface Heiko Carstens
2008-10-03 10:56 ` [PATCH/RFC 3/4] s390: convert etr/stp to stop_machine interface Heiko Carstens
2008-10-03 10:56 ` [PATCH/RFC 4/4] s390: convert to generic IPI infrstructure Heiko Carstens
2008-10-06  4:42 ` [PATCH/RFC 0/4] Add stop_machine_get/put_threads to stop_machine infrastructrue Rusty Russell
2008-10-06 20:16   ` Heiko Carstens
2008-10-07  1:39     ` Rusty Russell
2008-10-07 15:38       ` Heiko Carstens
2008-10-08  0:27         ` Rusty Russell
2008-10-08 10:14           ` Heiko Carstens
2008-10-09  0:18             ` Rusty Russell
2008-10-09 16:25               ` Heiko Carstens

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=20081003105632.357231142@de.ibm.com \
    --to=heiko.carstens@de.ibm.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=schwidefsky@de.ibm.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.