From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [RFC PATCH 0/5] module: Remove stop_machine from module unloading
Date: Wed, 03 Sep 2014 12:11:59 +0900 [thread overview]
Message-ID: <540686FF.4060907@hitachi.com> (raw)
In-Reply-To: <20140825105520.21089.26870.stgit@kbuild-fedora.novalocal>
Ping? :)
(2014/08/25 19:55), Masami Hiramatsu wrote:
> Hi,
>
> Here is a series of patches which remove stop_machine() from
> module unloading.
>
> Currently, each module unloading calls stop_machine()s 2 times.
> One is for safely removing module from lists and one is to
> check the reference counter. However, both are not necessary
> for those purposes (required by current implementation).
>
> First, we can use RCU for the list operation, we just need
> a synchronize_rcu right before cleaning up.
> Second, the reference counter can be checked atomically by
> using atomic_t, instead of per-cpu module_ref. Of course,
> for BIG SMP machines, atomic operation is not efficient.
> However, they usually don't need to remove most of modules too.
>
> In this series, I just fixed to use RCU for the module(and
> bugs) list for the first stop_machine.
> And for the second one, I replaced module_ref with atomic_t
> and introduced a "module lockup" module load option, which
> makes a module un-removable (lock up the module in kernel).
> The lockup modules can not be removed except forced, and the
> kernel skips module refcounting on those modules. Thus we
> can minimize the performance impact on the BIG SMP machines.
>
> BTW, of course this requires to update libkmod to support
> new MODULE_INIT_LOCKUP_MODULE flag. I'm not sure where is
> good to send the patches I have. Sould I better sending
> kmod patches on LKML?
>
> Thank you,
>
> ---
>
> Masami Hiramatsu (5):
> module: Wait for RCU synchronizing before releasing a module
> module: Unlink module with RCU synchronizing instead of stop_machine
> lib/bug: Use RCU list ops for module_bug_list
> module: Lock up a module when loading with a LOCLUP flag
> module: Remove stop_machine from module unloading
>
>
> include/linux/module.h | 22 ++----
> include/trace/events/module.h | 2 -
> include/uapi/linux/module.h | 1
> kernel/module.c | 147 +++++++++++++++++------------------------
> lib/bug.c | 20 ++++--
> 5 files changed, 85 insertions(+), 107 deletions(-)
>
> --
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
prev parent reply other threads:[~2014-09-03 3:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-25 10:55 [RFC PATCH 0/5] module: Remove stop_machine from module unloading Masami Hiramatsu
2014-08-25 10:55 ` [RFC PATCH 1/5] module: Wait for RCU synchronizing before releasing a module Masami Hiramatsu
2014-08-25 10:55 ` [RFC PATCH 2/5] module: Unlink module with RCU synchronizing instead of stop_machine Masami Hiramatsu
2014-08-25 10:55 ` [RFC PATCH 3/5] lib/bug: Use RCU list ops for module_bug_list Masami Hiramatsu
2014-08-25 10:55 ` [RFC PATCH 4/5] module: Lock up a module when loading with a LOCLUP flag Masami Hiramatsu
2014-08-26 5:30 ` Lucas De Marchi
2014-08-26 9:26 ` Masami Hiramatsu
2014-08-26 12:04 ` [RFC PATCH 0/2] kmod: Support lockup option to make module un-removable Masami Hiramatsu
2014-08-26 12:04 ` [RFC PATCH 1/2] libkmod: support lockup module option Masami Hiramatsu
2014-08-26 12:04 ` [RFC PATCH 2/2] modprobe: Add --lockup option to make module unremovable Masami Hiramatsu
2014-09-01 22:17 ` [RFC PATCH 0/2] kmod: Support lockup option to make module un-removable Lucas De Marchi
2014-10-13 4:41 ` Rusty Russell
2014-08-25 10:55 ` [RFC PATCH 5/5] module: Remove stop_machine from module unloading Masami Hiramatsu
2014-10-13 4:40 ` Rusty Russell
2014-10-21 10:34 ` Masami Hiramatsu
2014-10-22 4:25 ` Rusty Russell
2014-10-21 11:27 ` Masami Hiramatsu
2014-09-03 3:11 ` Masami Hiramatsu [this message]
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=540686FF.4060907@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=rusty@rustcorp.com.au \
/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.