LKML Archive on
help / color / mirror / Atom feed
From: Heiko Carstens <>
Subject: [PATCH/RFC v2 0/6] Convert stop_machine to use a workqueue
Date: Mon, 13 Oct 2008 23:50:07 +0200	[thread overview]
Message-ID: <> (raw)

Version 2: This is version 2 which converts stop_machine to a workqueue based
           implementation as suggested by Rusty instead of trying to extend
           the current kernel thread approach.

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 changes the current stop_machine code to
use a workqueue instead of kernel threads to synchronize all cpus.
This has the advantage that all per cpu workqueue threads are already running
when stop_machine gets called and therefore no memory needs to be allocated.
In addition stop_machine cant't fail anymore (free_module() relies on that).

A few things that need to be addressed:
- stop_machine gets called from initcalls, so we need to make sure that it
  is already initialized and has its workqueue started before that. For that
  a pre_smp initcall (early_initcall) is used to initialize it.
- the stop_machine kernel threads used to be rt kernel threads. Workqueues
  are normal threads. To get high priority threads a new interface
  create_rt_workqueue is introduced.

Patch 1 Moves the call to init_workqueue before pre smp initcalls
Patch 2 introduces create_rt_workqueue
Patch 3 converts stop_machine to use an rt workqueue
Patch 4 adds special case handling for num_online_cpus == 1 to stop_machine
        - Patch 4 is only needed if there would be a stop_machine call before
          the pre smp initcalls have been executed. As far as I can see there
          is currently none.
Patch 5 converts the s390 etr and stp code to use stop_machine
Patch 6 converts s390 to the generic IPI interface


             reply	other threads:[~2008-10-13 21:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-13 21:50 Heiko Carstens [this message]
2008-10-13 21:50 ` [PATCH/RFC v2 1/6] Call init_workqueues before pre smp initcalls Heiko Carstens
2008-10-13 21:50 ` [PATCH/RFC v2 2/6] workqueue: introduce create_rt_workqueue Heiko Carstens
2008-10-21 22:15   ` Rusty Russell
2008-10-13 21:50 ` [PATCH/RFC v2 3/6] stop_machine: use workqueues instead of kernel threads Heiko Carstens
2008-10-13 21:50 ` [PATCH/RFC v2 4/6] stop_machine: special case for one cpu Heiko Carstens
2008-10-13 21:50 ` [PATCH/RFC v2 5/6] s390: convert etr/stp to stop_machine interface Heiko Carstens
2008-10-13 21:50 ` [PATCH/RFC v2 6/6] s390: convert to generic IPI infrstructure Heiko Carstens
2008-10-16 10:38 ` [PATCH/RFC v2 0/6] Convert stop_machine to use a workqueue Rusty Russell

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH/RFC v2 0/6] Convert stop_machine to use a workqueue' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).