From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
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: Mon, 6 Oct 2008 22:16:50 +0200 [thread overview]
Message-ID: <20081006201650.GA4708@osiris.boeblingen.de.ibm.com> (raw)
In-Reply-To: <200810061542.41224.rusty@rustcorp.com.au>
On Mon, Oct 06, 2008 at 02:42:40PM +1000, Rusty Russell wrote:
> On Friday 03 October 2008 20:56:32 you wrote:
> > However we need to be able to do that without allocating any memory.
>
> Nice work Heiko!
>
> See free_module(), which calls stop_machine and, well, just hopes it works.
> So we've needed this for a while.
Ah, good. At least there is one other user then :)
> > Patch 1 is a stop_machine bugfix and is independent of the rest
> Hmm, do you actually need this? It was a whim (and clearly a dumb one). I'm
> tempted to change it to:
>
> err = smdata->fn(smdata->data);
> if (err)
> smdata->fnret = err;
That looks much better than the cmpxchg loop I came up with. All we need to
know is that 'something' went wrong. Any return code != 0 should be enough.
> > 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?
Anyway, I'm going to send a hopefully better patch tommorrow.
next prev parent reply other threads:[~2008-10-06 20:17 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 [this message]
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=20081006201650.GA4708@osiris.boeblingen.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.