From: Andrew Morton <akpm@linux-foundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: sjenning@linux.vnet.ibm.com, dan.magenheimer@oracle.com,
devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, ngupta@vflare.org, minchan@kernel.org,
mgorman@suse.de, fschmaus@gmail.com, andor.daam@googlemail.com,
ilendir@googlemail.com
Subject: Re: [PATCH 2/8] mm: frontswap: lazy initialization to allow tmem backends to build/run as modules
Date: Fri, 16 Nov 2012 15:16:19 -0800 [thread overview]
Message-ID: <20121116151619.aa60acff.akpm@linux-foundation.org> (raw)
In-Reply-To: <1352919432-9699-3-git-send-email-konrad.wilk@oracle.com>
On Wed, 14 Nov 2012 13:57:06 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> From: Dan Magenheimer <dan.magenheimer@oracle.com>
>
> With the goal of allowing tmem backends (zcache, ramster, Xen tmem) to be
> built/loaded as modules rather than built-in and enabled by a boot parameter,
> this patch provides "lazy initialization", allowing backends to register to
> frontswap even after swapon was run. Before a backend registers all calls
> to init are recorded and the creation of tmem_pools delayed until a backend
> registers or until a frontswap put is attempted.
>
>
> ...
>
> --- a/mm/frontswap.c
> +++ b/mm/frontswap.c
> @@ -80,6 +80,18 @@ static inline void inc_frontswap_succ_stores(void) { }
> static inline void inc_frontswap_failed_stores(void) { }
> static inline void inc_frontswap_invalidates(void) { }
> #endif
> +
> +/*
> + * When no backend is registered all calls to init are registered and
What is "init"? Spell it out fully, please.
> + * remembered but fail to create tmem_pools. When a backend registers with
> + * frontswap the previous calls to init are executed to create tmem_pools
> + * and set the respective poolids.
Again, seems really hacky. Why can't we just change callers so they
call things in the correct order?
> + * While no backend is registered all "puts", "gets" and "flushes" are
> + * ignored or fail.
> + */
> +static DECLARE_BITMAP(need_init, MAX_SWAPFILES);
> +static bool backend_registered __read_mostly;
> +
> /*
> * Register operations for frontswap, returning previous thus allowing
> * detection of multiple backends and possible nesting.
> @@ -87,9 +99,19 @@ static inline void inc_frontswap_invalidates(void) { }
> struct frontswap_ops frontswap_register_ops(struct frontswap_ops *ops)
> {
> struct frontswap_ops old = frontswap_ops;
> + int i;
>
> frontswap_ops = *ops;
> frontswap_enabled = true;
> +
> + for (i = 0; i < MAX_SWAPFILES; i++) {
> + if (test_and_clear_bit(i, need_init))
ooh, that wasn't racy ;)
> + (*frontswap_ops.init)(i);
> + }
> + /* We MUST have backend_registered called _after_ the frontswap_init's
> + * have been called. Otherwise __frontswap_store might fail. */
Comment makes no sense - backend_registered is not a function.
Also, let's lay the comments out conventionally please:
/*
* We MUST have backend_registered called _after_ the frontswap_init's
* have been called. Otherwise __frontswap_store might fail.
*/
> + barrier();
> + backend_registered = true;
> return old;
> }
> EXPORT_SYMBOL(frontswap_register_ops);
>
> ...
>
> @@ -226,12 +266,15 @@ void __frontswap_invalidate_area(unsigned type)
> {
> struct swap_info_struct *sis = swap_info[type];
>
> - BUG_ON(sis == NULL);
> - if (sis->frontswap_map == NULL)
> - return;
> - frontswap_ops.invalidate_area(type);
> - atomic_set(&sis->frontswap_pages, 0);
> - memset(sis->frontswap_map, 0, sis->max / sizeof(long));
> + if (backend_registered) {
> + BUG_ON(sis == NULL);
> + if (sis->frontswap_map == NULL)
> + return;
> + (*frontswap_ops.invalidate_area)(type);
> + atomic_set(&sis->frontswap_pages, 0);
> + memset(sis->frontswap_map, 0, sis->max / sizeof(long));
> + }
> + clear_bit(type, need_init);
> }
> EXPORT_SYMBOL(__frontswap_invalidate_area);
>
> @@ -364,6 +407,9 @@ static int __init init_frontswap(void)
> debugfs_create_u64("invalidates", S_IRUGO,
> root, &frontswap_invalidates);
> #endif
> + bitmap_zero(need_init, MAX_SWAPFILES);
unneeded?
> + frontswap_enabled = 1;
> return 0;
> }
>
> ...
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: sjenning@linux.vnet.ibm.com, dan.magenheimer@oracle.com,
devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, ngupta@vflare.org, minchan@kernel.org,
mgorman@suse.de, fschmaus@gmail.com, andor.daam@googlemail.com,
ilendir@googlemail.com
Subject: Re: [PATCH 2/8] mm: frontswap: lazy initialization to allow tmem backends to build/run as modules
Date: Fri, 16 Nov 2012 15:16:19 -0800 [thread overview]
Message-ID: <20121116151619.aa60acff.akpm@linux-foundation.org> (raw)
In-Reply-To: <1352919432-9699-3-git-send-email-konrad.wilk@oracle.com>
On Wed, 14 Nov 2012 13:57:06 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> From: Dan Magenheimer <dan.magenheimer@oracle.com>
>
> With the goal of allowing tmem backends (zcache, ramster, Xen tmem) to be
> built/loaded as modules rather than built-in and enabled by a boot parameter,
> this patch provides "lazy initialization", allowing backends to register to
> frontswap even after swapon was run. Before a backend registers all calls
> to init are recorded and the creation of tmem_pools delayed until a backend
> registers or until a frontswap put is attempted.
>
>
> ...
>
> --- a/mm/frontswap.c
> +++ b/mm/frontswap.c
> @@ -80,6 +80,18 @@ static inline void inc_frontswap_succ_stores(void) { }
> static inline void inc_frontswap_failed_stores(void) { }
> static inline void inc_frontswap_invalidates(void) { }
> #endif
> +
> +/*
> + * When no backend is registered all calls to init are registered and
What is "init"? Spell it out fully, please.
> + * remembered but fail to create tmem_pools. When a backend registers with
> + * frontswap the previous calls to init are executed to create tmem_pools
> + * and set the respective poolids.
Again, seems really hacky. Why can't we just change callers so they
call things in the correct order?
> + * While no backend is registered all "puts", "gets" and "flushes" are
> + * ignored or fail.
> + */
> +static DECLARE_BITMAP(need_init, MAX_SWAPFILES);
> +static bool backend_registered __read_mostly;
> +
> /*
> * Register operations for frontswap, returning previous thus allowing
> * detection of multiple backends and possible nesting.
> @@ -87,9 +99,19 @@ static inline void inc_frontswap_invalidates(void) { }
> struct frontswap_ops frontswap_register_ops(struct frontswap_ops *ops)
> {
> struct frontswap_ops old = frontswap_ops;
> + int i;
>
> frontswap_ops = *ops;
> frontswap_enabled = true;
> +
> + for (i = 0; i < MAX_SWAPFILES; i++) {
> + if (test_and_clear_bit(i, need_init))
ooh, that wasn't racy ;)
> + (*frontswap_ops.init)(i);
> + }
> + /* We MUST have backend_registered called _after_ the frontswap_init's
> + * have been called. Otherwise __frontswap_store might fail. */
Comment makes no sense - backend_registered is not a function.
Also, let's lay the comments out conventionally please:
/*
* We MUST have backend_registered called _after_ the frontswap_init's
* have been called. Otherwise __frontswap_store might fail.
*/
> + barrier();
> + backend_registered = true;
> return old;
> }
> EXPORT_SYMBOL(frontswap_register_ops);
>
> ...
>
> @@ -226,12 +266,15 @@ void __frontswap_invalidate_area(unsigned type)
> {
> struct swap_info_struct *sis = swap_info[type];
>
> - BUG_ON(sis == NULL);
> - if (sis->frontswap_map == NULL)
> - return;
> - frontswap_ops.invalidate_area(type);
> - atomic_set(&sis->frontswap_pages, 0);
> - memset(sis->frontswap_map, 0, sis->max / sizeof(long));
> + if (backend_registered) {
> + BUG_ON(sis == NULL);
> + if (sis->frontswap_map == NULL)
> + return;
> + (*frontswap_ops.invalidate_area)(type);
> + atomic_set(&sis->frontswap_pages, 0);
> + memset(sis->frontswap_map, 0, sis->max / sizeof(long));
> + }
> + clear_bit(type, need_init);
> }
> EXPORT_SYMBOL(__frontswap_invalidate_area);
>
> @@ -364,6 +407,9 @@ static int __init init_frontswap(void)
> debugfs_create_u64("invalidates", S_IRUGO,
> root, &frontswap_invalidates);
> #endif
> + bitmap_zero(need_init, MAX_SWAPFILES);
unneeded?
> + frontswap_enabled = 1;
> return 0;
> }
>
> ...
>
next prev parent reply other threads:[~2012-11-16 23:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-14 18:57 [PATCH v2] enable all tmem backends to be built and loaded as modules Konrad Rzeszutek Wilk
2012-11-14 18:57 ` Konrad Rzeszutek Wilk
2012-11-14 18:57 ` [PATCH 1/8] mm: cleancache: lazy initialization to allow tmem backends to build/run " Konrad Rzeszutek Wilk
2012-11-14 18:57 ` Konrad Rzeszutek Wilk
2012-11-16 23:10 ` Andrew Morton
2012-11-16 23:10 ` Andrew Morton
2013-01-30 15:57 ` Konrad Rzeszutek Wilk
2013-01-30 15:57 ` Konrad Rzeszutek Wilk
2012-11-14 18:57 ` [PATCH 2/8] mm: frontswap: " Konrad Rzeszutek Wilk
2012-11-14 18:57 ` Konrad Rzeszutek Wilk
2012-11-16 23:16 ` Andrew Morton [this message]
2012-11-16 23:16 ` Andrew Morton
2012-11-19 0:53 ` Bob Liu
2012-11-19 0:53 ` Bob Liu
2012-11-19 22:25 ` Andrew Morton
2012-11-19 22:25 ` Andrew Morton
2012-11-27 21:26 ` Konrad Rzeszutek Wilk
2012-11-27 21:26 ` Konrad Rzeszutek Wilk
2013-01-30 15:55 ` Konrad Rzeszutek Wilk
2013-01-30 15:55 ` Konrad Rzeszutek Wilk
2012-11-14 18:57 ` [PATCH 3/8] frontswap: Make frontswap_init use a pointer for the ops Konrad Rzeszutek Wilk
2012-11-14 18:57 ` Konrad Rzeszutek Wilk
2012-11-14 18:57 ` [PATCH 4/8] cleancache: Make cleancache_init " Konrad Rzeszutek Wilk
2012-11-14 18:57 ` Konrad Rzeszutek Wilk
2012-11-14 18:57 ` [PATCH 5/8] staging: zcache2+ramster: enable ramster to be built/loaded as a module Konrad Rzeszutek Wilk
2012-11-14 18:57 ` Konrad Rzeszutek Wilk
2012-11-14 18:57 ` [PATCH 6/8] staging: zcache2+ramster: enable zcache2 " Konrad Rzeszutek Wilk
2012-11-14 18:57 ` Konrad Rzeszutek Wilk
2012-11-14 18:57 ` [PATCH 7/8] xen: tmem: enable Xen tmem shim " Konrad Rzeszutek Wilk
2012-11-14 18:57 ` Konrad Rzeszutek Wilk
2012-11-14 18:57 ` [PATCH 8/8] xen/tmem: Remove the subsys call Konrad Rzeszutek Wilk
2012-11-14 18:57 ` Konrad Rzeszutek Wilk
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=20121116151619.aa60acff.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andor.daam@googlemail.com \
--cc=dan.magenheimer@oracle.com \
--cc=devel@linuxdriverproject.org \
--cc=fschmaus@gmail.com \
--cc=ilendir@googlemail.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=sjenning@linux.vnet.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.