All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: jens.axboe@oracle.com, schwidefsky@de.ibm.com,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH/RFC 0/4] Add stop_machine_get/put_threads to stop_machine infrastructrue.
Date: Wed, 8 Oct 2008 10:27:04 +1000	[thread overview]
Message-ID: <200810081127.05311.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20081007153854.GA4122@osiris.boeblingen.de.ibm.com>

On Wednesday 08 October 2008 02:38:54 Heiko Carstens wrote:
> On Tue, Oct 07, 2008 at 11:39:58AM +1000, Rusty Russell wrote:
> > That's exactly my idea.  We kmalloc already because NR_CPUS might be too
> > big for the stack.  This version would just kmalloc a struct containing
> > everything we need.
>
> Ok, I did that but the resulting code is astonishingly ugly, so I thought I
> should share it :)

Yeah, the diffstat tells the story.

> Another thing that comes to mind is cpu hotplug: if somebody issued
> stop_machine_prepare() and then a cpu hotplug operation gets started we
> need to create or kill a kstop thread. For that we need the "sm" so we can
> save/find the task_struct pointer of the thread.

Erk, good point.  Suckage.

OK, idea #2.  Let's just always have a kstopmachine thread running on every 
online cpu.  Is there a sane way to reuse the workqueue threads for this?

Thanks,
Rusty.


  reply	other threads:[~2008-10-08  0:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-03 10:56 [PATCH/RFC 0/4] Add stop_machine_get/put_threads to stop_machine infrastructrue Heiko Carstens
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 [this message]
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=200810081127.05311.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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.