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
Subject: Re: [PATCH/RFC 0/4] Add stop_machine_get/put_threads to stop_machine infrastructrue.
Date: Tue, 7 Oct 2008 11:39:58 +1000 [thread overview]
Message-ID: <200810071239.58732.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20081006201650.GA4708@osiris.boeblingen.de.ibm.com>
On Tuesday 07 October 2008 07:16:50 Heiko Carstens wrote:
> > > Patch 2 introduces the new proposed interface
> >
> > Could we just encapsulate the threads etc. into a "struct stopmachine"
> > which is returned from stop_machine_prepare(), then implement everything
> > in terms of that?
>
> You mean that we put the pointers to the threads, the cpu mask, etc. in
> this structure, instead of wasting bss size?
> That would be just a kmalloc call in __stop_machine_get_threads().
> Or do you think of something different?
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.
I prefer _prepare() / _run() / _destroy() as nomenclature BTW. prepare comes
from wait.h's prepare_to_wait; I don't like alloc() since it does more than
allocate memory, yet _get_threads unnecessarily reveals too much about the
implementation.
Then we have the simple case:
static inline int stop_machine(int (*fn)(void *), void *data,
const struct cpumask *cpus)
{
struct stop_machine *sm = stop_machine_prepare();
int err;
if (!sm)
return -ENOMEM;
err = stop_machine_run(sm, fn, data, cpus);
stop_machine_destroy(sm);
return err;
}
I think you want to be able to call stop_machine_run() with the same "sm"
multiple times, but that should be pretty easy to ensure.
Cheers!
Rusty.
next prev parent reply other threads:[~2008-10-07 1:40 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 [this message]
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=200810071239.58732.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=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.